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Abstract 


The  Expeditionary  Warfare  Decision  Support  System  (EDSS)  is  an  Office  of  Naval  Research 
(ONR)  sponsored  system  designed  to  improve  the  planning  of  expeditionary  operations.  ONR 
requested  that  the  Applied  Physics  Laboratory,  University  of  Washington  (APL-UW)  and  the 
Naval  Research  Laboratory  (NRL)  investigate  the  human-computer  interaction  (HCI) 
components  of  EDSS.  Additionally,  APL-UW  and  NRL  were  tasked  to  provide  user  interface 
recommendations  to  the  EDSS  developers.  To  do  this  the  HCI  team  followed  a  user-centered 
design  (UCD)  approach  and  studied  EDSS  users  and  their  tasks,  which  resulted  in  an  in-depth 
user  task  analysis  of  expeditionary  planning.  A  medium- fidelity  interface  prototype  was  created 
based  on  the  user  studies  and  the  principles  of  UCD.  The  prototype  presented  a  more 
streamlined  and  intuitive  order  of  tasks  and  improved  window  organization.  The  positive 
feedback  from  this  prototype  allowed  for  a  more  comprehensive  list  of  user  interface 
recommendations.  A  majority  of  these  recommendations  were  incorporated  into  a  follow-on 
version  of  EDSS.  HCI  and  UCD  have  implications  for  future  versions  of  EDSS  and  other  Navy 
decision  systems,  and  particularly  for  Net  Centric  Warfare. 
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I.  Introduction 

Expeditionary  warfare  planning  is  one  of  the  most  complex  endeavors  in  modem  military 
operations.  The  process  of  projecting  power  ashore  includes  operations  over  water,  under  water, 
in  the  air,  and  on  land.  Planning  considerations  range  from  detailed  study  of  tidal  information  to 
determining  how  and  when  to  move  bullets  from  ship  to  shore.  Also,  the  complexity  of  the 
planning  increases  when  military  operations  involve  multiple  services  or  multiple  warfare  areas. 
Hence,  expeditionary  warfare  is  even  more  complex  because  it  is  inherently  a  joint  operation 
(Joint  Doctrine  for  Amphibious  Operations — Joint  Pub  3-02,  9/19/2001).  Therefore,  planners 
must  master  the  full  spectrum  of  multiservice  operations,  and  also  navigate  the  oftentimes 
conflicting  procedures  of  separate  military  organizations. 

This  report  describes  the  work  accomplished  for  the  Office  of  Naval  Research  (ONR)  to  support 
the  Expeditionary  Decision  Support  System  (EDSS),  which  is  a  computer-based  system  designed 
to  improve  Navy  and  Marine  Corps  expeditionary  planning.  The  current  EDSS  system  provides 
powerful  tools  to  develop  a  plan  and  monitor  its  real-time  execution. 

ONR  requested  that  the  Naval  Research  Laboratory,  Washington,  D.C.  (NRL),  and  the  Applied 
Physics  Laboratory  at  the  University  of  Washington,  Seattle,  WA  (APL-UW),  investigate  the 
human-computer  interaction  (HCI)  aspects  of  EDSS  and  provide  recommendations  for 
improvement.  In  the  process  of  studying  EDSS  and  expeditionary  warfare,  NRL  and  APL-UW 
visited  several  sites,  interviewed  subject  matter  experts,  participated  in  EDSS  training  periods, 
and  went  aboard  ship  during  an  at-sea  amphibious  exercise. 

The  following  sections  1)  review  the  key  concepts  and  techniques  of  HCI  and  user-centered 
design  (UCD);  2)  describe  the  process  that  the  investigative  team  followed;  3)  provide  the  results 
of  the  user  interface  analysis;  4)  summarize  the  team’s  recommendations  and  their 
implementation;  and  5)  provide  a  conclusion  and  suggest  implications  for  future  design 
considerations.  The  latter  are  in  response  to  the  needs  of  a  major  military  initiative,  Net  Centric 
Warfare,  which  has  implications  far  into  the  future  for  transforming  military  operations.  This 
initiative  recognizes  that  at  the  center  of  all  technology  is  the  human  user.  EDSS  may  have  a 
valuable  role  in  this  operational  transformation. 
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11.  Human-Computer  Interaction  and  User-Centered  Design 

At  the  request  of  the  ONR  sponsor,  APL-UW  and  NRL  were  tasked  to  investigate  the  human- 
computer  interaction  (HCI)  aspects  of  EDSS  and  provide  support  to  the  EDSS  developers. 
(Note:  EDSS  developers  were  the  main  team  responsible  for  the  EDSS  software  and  not  the 
APL-UW/NRL  team.)  The  general  consensus  prior  to  the  start  of  the  HCI  work  was  that,  while 
EDSS  was  a  capable  application,  its  iterative  development  cycle  had  resulted  in  a  cumbersome 
and  unintuitive  user  interface. 

Coincident  with  the  start  of  the  HCI  work,  the  EDSS  developers  were  preparing  to  begin  a  major 
code  redesign  to  support  changes  in  the  Department  of  Defense’s  Common  Operating 
Environment  (COE).  This  offered  an  opportunity  to  make  relatively  low-cost  changes  to  the 
interface  paradigm  with  a  high  payoff  in  usability.  With  that  goal  in  mind,  the  HCI  team  felt  that 
the  principles  of  UCD  should  be  applied  during  the  redesign  effort.  The  following  section 
provides  background  information  on  key  concepts  and  techniques  of  HCI  and  UCD. 


What  is  Human-Computer  Interaction? 

The  discipline  of  human-computer  interaction  is  relatively  new.  One  of  the  most  broadly 
accepted  definitions  of  HCI  is  that  it  is  concerned  with  the  design,  evaluation,  and 
implementation  of  interactive  computing  systems  for  human  use  and  with  the  study  of  major 
phenomena  surrounding  them.  {ACM  SGICHI,  1992)  The  field  has  grown  rapidly  due  to  the 
exponential  expansion  of  computer  systems  into  nearly  all  facets  of  human  activity.  HCI  is 
multidisciplinary.  The  field  includes  computer  scientists,  linguists,  communication  experts, 
sociologists,  psychologists,  and  many  others. 

HCI  research  and  application  involves  a  variety  of  thrusts  such  as  human  perception  and  its 
relationship  to  graphical  user  interfaces,  or  the  impact  of  mental  models  on  a  system’s  ease  of 
use.  Yet,  at  the  core  of  HCI  is  the  concern  that  computers  need  to  be  designed  with  human 
capabilities  in  mind,  and  that  human  performance  requirements  should  be  factored  into  the 
overall  design  of  any  computer  system. 

“Underlying  all  HCI  research  and  design  is  the  belief  that  the  people  using  a  computer  system 
should  come  first.  Their  needs,  capabilities  and  preferences  for  performing  various  activities 
should  inform  the  ways  in  which  systems  are  designed  and  implemented.  People  should  not 
have  to  change  radically  to  ‘fit  in  with  the  system,’  [rather,]  the  system  should  be  designed  to 
match  their  requirements.”  {Preece,  1994) 


Usability 

The  process  of  improving  a  computing  system  so  that  it  meets  the  needs  and  capabilities  of  a 
user  is  often  described  as  increasing  the  system’s  usability.  This  term  can  be  interpreted  several 
ways.  Jakob  Nielsen,  a  well  known  usability  expert,  describes  the  factors  of  a  usable  system: 
leamability — the  system  should  be  easy  to  learn  and  help  the  user  toward  mastery;  efficiency — 
once  the  system  is  mastered,  the  user  should  achieve  a  high  level  of  productivity; 
memorability — a  casual  user  should  be  able  to  return  to  the  system  without  having  to  relearn  the 
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system;  low  errors — systems  should  have  few  bugs  and  be  able  to  recover  quickly  from  a  system 
failure;  satisfaction — systems  should  be  pleasant  to  use  so  that  users  like  using  them  ( Barnum , 
2002). 


The  Need  for  User-Centered  Design 

The  knowledge  gained  from  the  study  of  HCI  and  usability  has  led  to  a  new  paradigm  in 
computer  system  development  called  user-centered  design  (UCD).  UCD  was  developed  to 
address  the  complaint  that  computer  systems  were  too  complicated.  The  six  principles  of  UCD 
expressed  by  Vredenburg  et  al.  (2002)  are: 

■  Set  business  goals — determine  the  target  users 

■  Understand  users — the  needs  of  users  are  the  driving  force 

■  Design  the  total  user  experience — every  aspect  of  the  system  can  affect  the  user 

■  Evaluate  designs — user  feedback  is  required 

■  Assess  competitiveness — users  often  have  more  than  one  option 

■  Manage  for  users — continue  to  seek  user  feedback  and  include  user  needs  during  the 
systems’  life  cycle 


UCD  is  a  way  of  achieving  more  effective  systems  by  challenging  the  designers  to  mold  the 
system  around  the  user.  Designers  must  start  with  the  users’  needs  before  deciding  the 
technological  approach.  Good  UCD  leads  to  increased  usability  because  UCD  is  “. .  .an  approach 
to  designing  ease  of  use  into  the  total  user  experience  with  products  and  systems.  It  involves  two 
fundamental  elements — multidisciplinary  teamwork  and  a  set  of  specialized  methods  [for] 
acquiring  user  input  and  converting  it  into  design.”  (  Vredenburg  et  al.,  2002) 

Another  aspect  of  UCD  is  that  it  leads  to  better  “situational  awareness”  because  the  system  is 
designed  after  a  thorough  understanding  of  the  users’  tasks  and  information  needs  (Ends ley, 
2003).  For  decision  systems  like  EDSS,  situational  awareness  should  be  a  primary  concern. 


Task  Analysis 

Because  one  of  the  essential  tenets  of  UCD  is  designing  for  the  human  in  the  system,  designers 
need  to  understand  the  work  users  must  accomplish.  In  the  fields  of  HCI  and  cognitive 
engineering  there  are  several  different  methodologies  used  to  develop  knowledge  about  users  and 
their  work  requirements.  These  methods  can  generally  be  grouped  together  as  task  analysis. 

Task  analysis  had  its  origins  in  the  studies  by  Taylor  and  others  (Annet,  2000)  of  human  motions 
on  factory  assembly  lines.  These  techniques  evolved  as  the  machines  used  by  humans  grew 
more  complex  and  required  more  than  just  physical  interactions.  The  development  of  computing 
systems  that  automate  human  processes  or  aid  in  high-level  decision  making  requires  an  even 
deeper  understanding  of  human  involvement  and  thought  processes. 

One  of  the  more  powerful  methodologies  is  called  cognitive  task  analysis  (CTA),  which 
“...attempts  to  apply  current  concepts  in  cognitive  psychology  to  the  analysis  of  complex  tasks.” 
(Schraagen  et  al.,  2000)  A  full  CTA  requires  in-depth  study  of  how  a  person  processes 
information,  forms  concepts,  and  makes  a  decision  based  on  those  concepts.  One  method  to 


3 


TR  0402 


UNIVERSITY  OF  WASHINGTON  •  APPLIED  PHYSICS  LABORATORY. 


extract  this  type  of  information  is  to  have  subject  matter  experts  (SME)  perform  a  representative 
task  and  externalize  their  internal  thoughts.  This  Think  Aloud  protocol  typically  requires  the 
recording  of  all  verbalizations  and  the  subsequent  analysis  of  each  statement.  Full  analysis  of  all 
the  Think  Aloud  statements  can  typically  take  months  of  work. 

Considering  the  short  time  frame  we  had  to  provide  design  recommendations  to  the  EDSS 
developers,  and  the  complexity  of  the  decisions  in  the  expeditionary  planning  domain,  we 
decided  to  employ  a  simpler  methodology  called  user  task  analysis  (UTA).  A  UTA  involves 
learning  from  an  SME  during  interviews,  observations,  and  from  published  materials  such  as 
doctrine  and  procedural  descriptions  [standard  operating  procedures  (SOP)]. 


Total  User  Experience 

Once  an  understanding  of  the  user  is  achieved,  the  design  of  any  cognitive  system,  that  is,  a 
system  with  humans  in  the  loop,  should  focus  on  meeting  the  identified  needs  of  those  humans. 
This  should  be  developed  with  a  holistic  viewpoint  and  a  consideration  for  the  total  user 
experience.  This  experience  includes  such  items  as  training  and  the  user’s  system  and  social 
environment.  The  design  should  focus  on  solutions  to  user  problems,  not  solutions  to  technology 
challenges. 

One  way  toward  achieving  a  system  that  is  both  usable  and  useful  is  to  include  people  from  a 
variety  of  disciplines  in  the  design  team.  This  allows  the  incorporation  of  different  perspectives 
on  the  needs  of  the  user.  People  with  field  or  operational  experience  and  those  with  multimedia 
or  technical  communications  training  can  greatly  enhance  the  total  user  experience  by  providing 
design  recommendations  that  go  beyond  solving  system  engineering  problems.  The  team  needs 
to  consider  issues  such  as  workflow,  training,  maintenance,  and  integration  with  other  tools  in 
the  users’  workplace. 

Another  user  experience  issue  that  engineers  often  relegate  to  a  low  priority  is  the  look  and  feel 
of  the  system  interface,  or,  its  visual  appeal.  A  distinctive  user  interface  enhances  the  user 
experience  because  it  plays  to  the  human  desire  for  proportionality,  clarity,  and  color. 
Proponents  of  great  looking  Web  sites,  for  example,  recognize  the  value  of  appearance  and 
distinctive  design  for  drawing  in  users,  keeping  them  interested,  and  in  getting  them  to  come 
back.  Lindholm  and  Tapani  (1994)  cite  beauty  as  an  important  property  for  an  interface. 

There  are  a  variety  of  techniques  that  the  design  team  can  use  to  help  achieve  a  good  user- 
centered  design,  such  as  heuristic  check  lists  and  cognitive  walkthroughs,  but  two  of  the  most 
important  are  rapid  prototyping  and  usability  testing. 

Briefly,  rapid  prototyping  is  the  early  development  of  a  user  interface  that  ties  together  the 
information  inputs  and  the  system  outputs.  A  prototype  can  be  either  low,  medium,  or  high 
fidelity,  but  considering  the  fast  pace  of  modem  software  development,  most  teams  rarely  have 
time  to  develop  a  high-fidelity  prototype  prior  to  lock-in  of  the  design  features.  The  intent  is  to 
test  ideas  before  the  final  design  has  been  decided,  not  just  before  it  is  implemented. 

The  prototype  plays  a  significant  role  in  the  early  stages  of  usability  testing.  A  low-fidelity 
prototype  can  be  brought  to  users  and  their  feedback  can  be  factored  into  the  early  stages  of  the 
system  design.  As  the  design  becomes  more  complete,  the  development  of  software  use  cases 
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should  be  checked  against  the  user’s  needs  as  described  in  the  task  analysis,  and  by  additional 
interviews  with  users. 

Finally,  after  most  of  the  design  decisions  have  been  made,  usability  testing  becomes  most 
important.  A  high-fidelity  prototype  should  be  created  that  allows  for  the  completion  of  real 
tasks.  Users  should  be  observed  using  this  system  and  data  from  those  observations  need  to  be 
analyzed.  Usability  testing  does  not  have  to  be  a  time  sink  or  costly.  Several  researchers 
(. Barnum ,  2003)  have  shown  that  a  small  number  of  users  (3  to  5)  who  are  observed  by  human 
recorders  (i.e.,  sophisticated  recording  systems  are  not  necessary)  can  catch  up  to  80%  of  a 
system’s  usability  problems. 

These  UCD  principles  and  techniques  formed  the  foundation  for  the  HCI  team’s  investigation 
effort  and  the  subsequent  user  interface  recommendations.  These  are  described  in  the  following 
sections. 
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111.  Investigation  and  Analysis 

As  described  in  the  previous  section,  the  HCI  team  determined  that  the  redesign  of  the  EDSS 
user  interface  should  follow  UCD  principles.  The  best  time  to  employ  UCD  is  at  the  beginning 
of  a  software  development  project,  but  in  this  case  the  UCD  procedures  had  to  be  altered  to 
accommodate  a  program  that  had  already  been  fielded.  An  additional  consideration  was  the 
desire  to  produce  interface  design  recommendations  as  soon  as  possible.  To  accomplish  this 
goal  the  team  adopted  a  two-step  process.  They  focused  on  the  usability  of  the  EDSS  program  at 
the  start  of  the  investigation  and  then  moved  to  a  more  comprehensive  user  task  analysis.  The 
ultimate  goal  was  to  gain  a  sufficient  understanding  of  the  expeditionary  warfare  domain. 


Usability  Study 

The  usability  study  was  conducted  by  several  methods.  The  first  task  was  an  interview  with  an 
EDSS  subject  matter  expert  (SME).  The  SME  had  extensive  knowledge  of  the  EDSS  program 
and  the  expeditionary  warfare  domain.  He  provided  an  in-depth  demonstration  of  EDSS 
capabilities.  This  was  filmed  and  later  used  for  team  training.  A  second  period  of  data 
collection  was  accomplished  during  a  scheduled  EDSS  training  period  on  the  USS  Tarawa 
(LHA-1)  at  pier  side,  San  Diego.  An  HCI  team  member  participated  in  the  training  and  then 
observed  the  sailors  and  marines  during  their  training,  documenting  when  the  trainees  had 
difficulties  learning  or  using  the  system. 

One  of  the  most  important  user  studies  was  an  observation  period  spent  on  the  USS  Two  Jima 
(LHD-7)  during  an  amphibious  exercise.  Here,  a  team  member  observed  multiple  training 
activities  and  the  operational  use  of  EDSS  in  exercise  planning,  and  conducted  numerous 
interviews  with  Marine  and  Navy  personnel.  Extensive  notes  on  the  use  of  the  EDSS  application 
during  simulated  wartime  situations  provided  the  best  understanding  of  its  strengths  and 
weaknesses. 

In  addition  to  working  with  users,  the  EDSS  developers  provided  the  HCI  team  with  a  version  of 
EDSS  l.X.  The  HCI  team  reviewed  all  the  functions  in  the  application  and  filmed  the 
completion  of  different  tasks.  The  availability  of  a  running  system  was  invaluable  for  the 
development  of  the  redesign  recommendations. 

The  first  result  of  these  interactions  with  users  was  the  development  of  a  workshop.  Its  main 
objective  was  to  introduce  some  of  the  usability  issues  discovered  and  also  provide  an  overview 
of  UCD  principles  to  the  EDSS  developers.  The  workshop  was  held  in  July  2002  and  a  variety 
of  UCD  topics  were  presented  (see  Appendix  A).  A  discussion  during  this  workshop  led  to  the 
initial  thoughts  on  a  new  human-computer  interface  paradigm. 


User  Interface  Analysis 

Following  the  workshop,  the  HCI  team  focused  on  the  EDSS  user  interface.  The  team 
determined  that  the  most  significant  impact  they  could  have  on  EDSS  would  be  to  help  improve 
how  users  interacted  with  the  menu  and  windows  of  the  current  fielded  system.  The 
investigative  team  conducted  an  initial  analysis  to  discover  why  users  were  having  difficulty 
traversing  EDSS  l.X.  We  discovered  a  number  of  factors.  Most  notable  were:  1)  the  system 
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lacked  workflow  or  a  first-to-last  step  organization;  2)  windows  opened  on  top  of  one  another, 
covering  the  map  and  causing  users  to  become  confused  because  they  could  not  see  their 
previous  entries;  3)  similar  or  related  tasks  were  not  grouped  logically;  and  4)  users  had  to  go 
through  too  many  steps  to  complete  a  task. 


Table  1  shows  the  top  level  menu  structure  of  the  EDSS  l.X  version  reviewed  by  the  HCI  team. 
The  team  learned  that  this  menu  structure  evolved  on  a  sometimes  ad  hoc  basis,  and  the  result 
was  a  confusing  structure  for  the  user.  For  example,  in  the  first  menu  the  term  “Operational 
Areas”  was  unclear.  Are  these  ship  operating  areas,  ground  areas,  air  areas,  or  is  something  else 
intended?  Under  this  menu  are  several  lines  for  tasks,  such  as  load  or  save.  But  there  is  also  a 
line  for  the  task  of  import  or  export.  How  is  importing  different  from  loading?  There  are 
numerous  other  examples  where  the  menus  were  sometimes  poorly  described  or  the  capability 
they  offered  the  user  was  placed  in  an  area  that  was  not  intuitive  and  hence  difficult  to  locate  in 
the  user  workflow. 


Table  1.  EDSS  l.X  Top  Level  Menu  Structure 
(Menus  in  parentheses  are  planned  but  not  implemented.) 

Operational  Areas 

New  Area  . . . 

Load  . . . 

Save  ... 

Delete  . . . 

Import . . . 

Export . . . 

Exit 

Display 

Plot  toggles... 

Time/Distance  Lines. . . 

Spider  Web... 

AO  A  Mgmt 

(Objective) 

(Order  of  Battle) 

Areas  . . . 

4W  Grid  Assignments  . . . 

Asset  Positions... 
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Envr  DB 

Database 

Depth  Profile  . . . 
(Wind) 

(Tide) 

(Wave) 

Models 

Surf  Forecast ... 

Surf  Observations  . . . 
(Tide  Model) 

Assault  Plans 

(Doctrine) 

(Lessons  Learned) 

Plan  Data 
Logistics 

Serial  Database  . . . 

Serial  Tracking. . . 

Reports 

Landing  Craft  Performance  . . . 
Landing  Craft  Availability  . . . 
Landing  Craft  Employment. . . 
Helo  Availability  . . . 

Helo  Employment . . . 

AAV  Availability. . . 

AAV  Employment. . . 


After  a  review  of  the  top  level  menus,  the  HCI  team  selected  several  major  tasks  and  performed 
the  workflow  required  of  the  tasks.  The  team  found  that  the  workflow  required  was  not  well 
thought  out  and  could  often  be  frustrating.  Windows  would  pop  up  and  overlay  the  window  on 
which  the  user  was  working.  Users  got  lost  as  they  navigated  to  the  new  window  to  enter  data 
and  then  tried  to  return  to  their  previous  window.  The  tasks  involved  in  building  a  Sea  Echelon 
Area  are  a  case  in  point:  the  Unix-based  version  (UBV)  EDSS  l.X  required  either  15  steps  to 
create  a  4W  Grid  (Table  2)  or  13  steps  to  create  a  Freehand  Area  (Table  3). 
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Table  2.  Create  4W  Grid 

Begin 

1)  Select  “AOA  Management/ Areas”  from  EDSS  Menu  bar 

2)  Select  “Add”  from  Area  Directory  panel 

3)  Select  “Grid”  from  list  of  area  types  (4W  Grid  Specifications  Window  is  displayed) 

Enter  4W  Grid  Specs 

4)  Enter  name  of  Grid 

5)  Select  Lat/Lon  field  then  click  on  map  to  set  Lat/Lon  of  Grid  center,  OR 
Enter  Latitude  and  Longitude  in  Lat/Lon  fields 

6)  Enter  Disposition  Axis 

7)  Enter  number  of  Cells 

8)  Enter  Cell  Spacing  Distance 
Name  4W Grid  Cells 

9)  Select  “AOA  Management/4W  Grid  Assignment”  from  EDSS  Menu  bar 

10)  Click  “4W  Grid”  button  (a  list  of  4  W  Grids  is  displayed) 

1 1)  Select  a  4W  Grid  from  list 

12)  Enter  user-specified  name  in  “Name”  field 

13)  Select  “Assignment”  field,  then  click  on  cell  to  name  on  map,  OR 
Enter  Cell  ID  in  “Assignment”  field 

14)  Enter  comments  in  “Remarks”  field 

15)  Select  cell  color  from  color  list 

Table  3.  Create  Freehand  Area 

Begin 

1)  Select  “AOA  Management/ Areas”  from  EDSS  Menu  bar 

2)  Select  “Add”  from  Area  Directory  panel 

3)  Select  “Polygon”  from  list  of  area  types 

Enter  Freehand  Area  Specs 

4)  Enter  name  of  Area 

5)  Select  area  type  (Area/Zone  is  default) 

Specify  Freehand  Area  points 

6)  Select  “Insert  Pt”  button 

7)  Click  on  the  map  to  create  points;  each  click  creates  a  new  point;  when  last  point  has 
been  created,  select  the  “Close”  button  to  close  the  area  and  end  the  insert  point 
mode,  OR  key  in  Lat/Lon  coordinates  of  the  point(s) 
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Insert  new  point(s)  in  existing  Freehand  Area 

8)  Select  a  field  from  the  list  of  points;  the  new  point  will  be  inserted  BEFORE  the 
selected  point 

9)  Select  the  “Insert  Pt”  button 

10)  Click  on  the  map  to  create  points;  each  click  creates  a  new  point;  when  last  point  has 
been  created,  select  the  “Close”  button  to  close  the  area  and  end  the  insert  point 
mode,  OR  key  in  Lat/Lon  coordinates  of  the  point(s) 

Move  existing  Freehand  Area  point 

11)  Select  field  of  point  to  move 

12)  Click  on  map;  the  point  will  move  to  the  position  of  the  click 

13)  Select  the  “Close”  button  to  re-close  the  area 


Similarly,  there  were  14  steps  to  create  a  Q-Route,  or  9  steps  to  create  a  Boat  Lane.  Once  the 
user  created  a  new  Boat  Lane,  the  lane  was  rendered  as  a  Q-Route.  To  edit  the  Boat  Lane,  the 
user  followed  the  previous  Q-Route  editing  procedures.  Either  way,  these  tasks  were 
unnecessarily  complicated. 


Figures  1-3  show  the  largely  text-based  screens  of  EDSS  l.X  with  confusing  window  layering. 
Again,  one  of  the  most  significant  problems  we  found  with  the  interface  was  the  windows 
management.  Windows  popped  in  front  of  other  windows  and  users  had  trouble  finding  the 
window  they  needed.  Also,  users  had  difficulty  finding  the  appropriate  task  menu  to  achieve 
their  desired  workflow.  These  menus  were  neither  grouped  logically  nor  named  intuitively. 


Figure  1.  Landing  Craft  and  Assault  text-based  windows  in  EDSS  l.X 
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Figure  2.  View  at  start  up  of  EDSS  l.X;  this  shows  all  level  2  tasks 
under  the  Expeditionary  Planning  supertask. 


Figure  3.  EDSS  l.X — editing  4W  Grid  parameters 
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User  Task  Analysis 

The  first  major  phase  of  the  user  task  analysis  was  completed  at  sea,  during  an  amphibious 
exercise  off  the  U.S.  East  Coast.  The  exercise  included  several  ships,  an  embarked  amphibious 
group  commander,  and  a  fleet  marine  force.  One  member  of  the  HCI  team  was  invited  to 
participate  and  was  allowed  to  observe  users  as  they  were  trained  on  EDSS.  The  team  member 
was  also  able  to  interview  several  other  exercise  participants.  Table  4  outlines  the  observed 
training. 


Table  4.  Observation  Record  of  EDSS  Training  on  USS  Iwo  Jinta  (LHD-7). 


Time 

User 

Comments 

August  13, 

2002 

(Tuesday) 

7:05  AM 
(approximately 

1  hr  15  min, 
with  time  for 
system 
glitches  not 
counted) 

Marine  BLT  - 
Pvt. 

Ops  specialist. 
Experienced 
with  software 
systems  and 
served  as 
regulation 
writer. 

Serial  tables  -  listing  of  equipment  in  order  to  keep  an 
organized  evolution  of  debarking  or  embarking  via  LCAC 
or  other  «became  much  more  familiar  with  these  later» 

Found  out  that  within  operational  area  it  is  possible  to  have 
multiple  beaches. 

Do  all  actions  in  1  table  before  going  on  to  the  next  action 
when  editing  speeds  under  scheduled  assault  wave. 

EDSS  capability  for  LOS  (line  of  sight):  the  ability  to 
present  height  and  define  an  area  for  the  projection  of  what 
is  visible  from  a  point.  Marines  liked  this  for  determining 
which  area  would  be  a  viable  approach  to  a  LZ  or  action 
area. 

Technical  question  re:  Q-Route,  the  Navy  considers  it  a 
mined  area  route.  In  EDSS,  Q-Route  is  any  route  used; 
thoughts  are  to  just  call  it  “Routes”  thus  making  it  possible 
to  design  multiple  routes  without  the  confusion  of 
nomenclature. 

Should  “Basic  Decisions”  be  a  step  when  it  really  seems  to 
be  a  part  of  most  cells?  It  is  separate  in  the  manual  so 
wondering  what  it  really  refers  to  here. 

Another  separate  section  in  the  manual  is  design  display. 
That  also  seems  to  be  something  that  is  done  and  refined 
throughout.  I  think  particularly  for  expert  users  it  would 
be  something  not  considered  a  lot  because  they  have 
defaults  in  their  mind  from  the  beginning. 
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Time 

User 

Comments 

August  13, 

2002 

(Tuesday) 

9:00  AM 
(approximately 

2  hr  with  many 
interruptions 
for  general 
explanations 
and  system 
crashes) 

Navy  SAC  - 
QM1  -  works  in 
Ops  specialty. 

Not  an  expert 
computer  user. 

Wanted  to  do  everything  with  the  mouse  and  “point  & 
click,”  and  did  not  like  “key”  commands. 

Very  uninformed  about  amphibious  operations  in  general. 
Much  training  time  was  also  spent  explaining  the  purpose 
of  various  EDSS  activities.  These  will  be  more  important 
to  him  as  he  goes  for  promotion  so  it  was  recognized  as  a 
training  tool  as  well  as  a  planning  tool.  Steps  were 
explained  as  create  Operational  Area,  then  do  the  4-W 
grid,  then  the  boat  lane  and  finally  boat  lanes. 

When  creating  beach  center  and  boat  lanes,  it  was  possible 
to  get  points  automatically. 

August  14, 

2002 

(Wednesday) 
7:30  AM 
(ended  at  9 

AM) 

Navy  SAC  - 
QM1  -  session 

2.  (He  had  mid 
watch  the  night 
before  and  was 
pretty  tired.) 

Performance  requirement  for  4W  Grid  should  include 
something  re:  providing  sufficient  operational  area  for 
participating  ships. 

Boat  lane  is  a  defined  area  on  the  chart  for  craft  to  use 
when  heading  towards  the  beach.  It  is  plotted 

perpendicular  to  the  beach  and  generally  starts 
approximately  4,000  feet  from  shore. 

Designing  routes  includes  planning  the  timing  for  all  craft 
in  and  out  with  on/off  load  times  figured  in.  Factors  that 
need  to  be  considered  (besides  not  bumping  into  other 
craft)  are  speeds  up  and  down  depending  on  loads,  sea 
conditions,  and  safety. 

Apparently  there  is  a  lot  of  convention  for  some  of  the 
design  factors.  I  think  the  use  of  a  default  based  on 
convention  would  be  a  time  saver.  Ability  to  change  if 
need  be  could  still  be  included. 

Ship-to-shore  movement  may  be  for  individual  craft  or 
waves  of  craft  with  individuals  then  figured.  Decisions  are 
wave  assault  order,  paths,  delays. 

Landing  plans  need  to  have  actual  times  and  relative 
movements  displayed. 

Part  of  boat  lane  construction  is  to  determine  the  need  for  a 
sea  lane  extension.  This  is  an  area  added  to  the  beginning 
of  the  boat  lane  to  allow  for  all  craft  to  be  dropped  off. 
The  newer  version  of  EDSS  has  this  capability. 
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Time 

User 

Comments 

August  14, 

2002 

(Wednesday) 
13:05  PM 
(approximately 
.5  hr) 

Marine  BLT  - 
Sgt. 

Ops  specialist 

Computer  smart  but  did  not  want  to  have  to  worry  about 
all  that  “Navy”  stuff. 

Basically  followed  same  steps  as  used  for  Cpl.  yesterday. 

Ended  up  taking  him  to  SAC  to  show  him  the  LOS  feature, 
which  is  still  not  installed  on  the  desktops  because  of  not 
having  external  floppy  drive. 

No  serial  table  availability  either,  which  is  the  other  thing 
they  would  have  been  interested  in  at  that  time. 

They  were  doing  some  preliminary  work  to  prepare  for 
when  they  were  going  to  get  the  order  to  begin  planning.  I 
wonder  if  that  would  be  a  true  example  of  how  long  it 
would  take  them  to  do  one  from  scratch? 

August  14, 

2002 

(Wednesday) 
13:35  PM 
(approximately 
.5  hr) 

Marine  BLT  - 
E3 

Ops  specialist 

Followed  the  same  procedure  as  the  one  before  and  had  the 
same  limitations. 

These  guys  were  good  on  computers  and  had  a  fair  amount 
of  knowledge  about  amphibious  planning. 

They  were  really  interested  in  the  maps,  which  were  not 
functional  at  this  time 

Lots  of  limitations  identified  because  system  was  not  on 
the  LAN  and  could  not  access  information  available 
through  GCSS. 

There  seemed  to  be  a  real  tendency  to  get  lost  in  the 
software  as  to  whether  they  were  doing  sea  or  land  ops  and 
which  things  were  important  for  them.  Possible  to  include 
some  way  of  identifying  which  ops  area  they  are  interested 
in  working?  Thus  marines  who  are  only  plotting  from 
beach  to  action  area  would  not  have  to  even  see  some  of 
the  other  stuff  if  they  have  no  desire  to  modify  the  boat 
lanes,  etc.  defined  by  someone  else.  Particularly  valuable 
when  EDSS  becomes  mobile  and  worked  by  all  rather  than 
as  stand-alone  as  it  was  here. 
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Time 

User 

Comments 

August  15, 

2002 

(Thursday) 

8:00  AM 
(approximately 

2  hr) 

Navy  -  QM1 
Session  3  (much 
less  fatigued  and 
much  more 
interested) 

Put  on  machine  that  finally  is  up  and  running  like  it  is 
supposed  to  be  at  this  point. 

Fair  amount  of  training  remembered.  Still  getting  lost 
some  though. 

Import  and  exporting  functions  were  not  working  correctly 
and  then  when  checked  it  was  impossible  to  tell  what  files 
were  the  ones  (if  any)  that  had  been  created.  Could  not  see 
date/time  stamps.  Made  suggestions  about  changing  that. 

Found  other  places  where  some  buttons  were  not 
consistent. 

Made  suggestion  to  have  a  “formal”  HF  evaluation  of 
software  to  check  for  inconsistencies  prior  to  getting  too 
far  along.  Easy  to  have  these  when  there  are  so  many 
modifications  going  on  all  the  time. 

August  15, 

2002 

(Thursday) 

10:00  AM 
(approximately 
.5  hr) 

Marine  BLT  - 
E3.  (did  not 
even  work  in  the 
area  but  saw 
what  was 
happening  and 
wanted  to  try  it 
out) 

(No  comments) 

August  15, 

2002 

(Thursday) 

18:00  PM 
(approximately 
1.5  hr) 

Navy  -  QMC 
works  in  ops 
(had  an  intro  on 
8/12  but  there 
were  so  many 
problems  with 
the  software,  I 
did  not  take  any 
training/planning 
notes) 

During  earlier  training  he  professed  not  to  know  a  lot 
about  amphibious  operations.  A  lot  of  time  spent  with 
how  to  get  from  screen  to  screen.  Said  that  he  did  not 
know  GCSS. 

He  remembered  a  EOT  from  the  earlier  session  despite  all 
the  problems  there  were  then.  I  ended  up  starting  his 
training  and  he  was  able  to  help  me  out  when  I  got  stuck. 

At  this  time  he  also  seemed  more  interested  than  he  did  in 
the  initial  session. 

Was  shown  all  features  this  time  and  seemed  to  have  a 
good  grasp  of  what  EDSS  could  do  for  them. 

The  second  phase  of  the  user  task  analysis  involved  an  in-depth  review  of  the  pertinent 
references  and  military  doctrine.  The  results  of  this  data  collection  are  compiled  in  a  user  task 
analysis  found  in  Appendix  B.  The  study  detailed  the  first  two  steps  of  the  mission  planning 
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processes:  Mission  Analysis  and  Course  of  Action  (CO A)  development.  This  identified  the 
sequence  and  steps  in  decision  making.  Further  breakdown  of  subtasks  focused  on  two  relevant 
tasks  for  our  purposes  here:  Sea  Echelon  Areas  and  Routes  or  Boat  Lanes.  The  study  identified 
the  information  and  performance  requirements,  the  process  involved,  and  the  primary  decision 
makers. 

The  next  section  describes  the  recommendations  that  were  provided  to  the  EDDS  development 
team.  These  recommendations  had  their  origin  in  the  initial  usability  studies,  but  the  knowledge 
we  gained  from  the  extensive  user  interaction  and  task  analysis  gave  these  recommendations  a 
more  solid  foundation. 
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IV.  User  Interface  Design  Recommendations 

The  Recommendations 

Based  on  the  study  of  EDSS  and  the  tasks  involved  in  expeditionary  planning,  the  investigative 
team  developed  the  following  recommendations  (see  Appendix  C  for  the  full  report). 

The  graphical  user  interface  (GUI)  needs  to: 

•  keep  the  map  window  in  the  center  of  the  user’s  vision;  all  other  interface  windows  form 
around  the  map  window 

•  restrict  window  proliferation  by  using  a  single  working  window  with  tabbed  panes 

•  offer  a  workflow  listing  as  a  series  of  tasks  that  segue  directly  to  the  required  data  entry 
tabs 

•  provide  an  asset  manager  window  that  links  objects  in  the  map  window  to  their  individual 
data  entry  tabs 

•  provide  a  quick  way  to  animate  a  COA  with  a  playback  slider  bar 

•  provide  a  consolidated  list  of  all  tasks  that  provides  a  hyperlink  to  the  actual  workflow 
task 

•  provide  “tool  tip”  pop-ups  (abbreviated  help  explanations)  when  the  user  moves  the 
mouse  over  key  elements  of  the  GUI 

The  investigative  team  conducted  an  intermediate  analysis  as  a  transition  toward  the  HCI 
prototype.  Figure  4  represents  the  steps  involved  in  creating  a  new  OpArea  that  were  taken  from 
EDSS  l.X.  The  resulting  workflow  allows  planners  to  select  a  task  and  plan  a  route  with  access 
to  all  information  clearly  visible  on  the  screen.  This  redesign  is  based  on  an  object-action 
interface  (OAI)  model  that  allowed  designers  to  decompose  a  complex  information  problem  into 
a  comprehensible  and  effective  solution  through  the  use  of  task  hierarchies  and  networks,  and 
information  actions  that  are  then  translated  into  interface  metaphors  or  objects  ( Shneiderman , 
1998). 

To  help  the  team  explain  its  ideas  for  a  new  interface  paradigm,  a  medium-fidelity  prototype  was 
developed.  This  prototype  (Figure  5  is  a  sample  screen  shot)  was  written  in  Java  and  was 
platform  independent.  It  featured  a  new  task  organization,  a  regrouping  of  data  entry  windows, 
and  a  new  way  of  grouping  assets.  The  prototype  also  allowed  a  user  to  complete  a  real  task, 
which  was  the  development  of  a  4W  grid  and  the  assignment  of  ship  names,  boat  lanes,  and 
landing  zones.  This  prototype  was  essential  in  convincing  the  developers  and  key  EDSS  SMEs 
of  the  usefulness  of  the  new  interface  design. 
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EDSS  Sample  Workflow 


Data 

Exported 


Open 

Operational 

Areas 


Correct 

Media 

Error 


Figure  4.  Unix-based  version’s  new  operational  area  workflow 


■!  Helo  Availability 
ss  AAV  Availability 
::  Serial  database 
o  Geographic  Overlays 
^b  Sea  Echelon  Areas 
-!!  Freehand 
-B4W  Grid 
*-■  Location 

■  Size 

■  Data 

■  Labels 
■:Boat  Lane 
::Q  Routes 

::  Helo  Landing  Zone 
Courses  of  Action 
•a  Execution  of  COA 
L-s  Serial  T racking 
:•  Display  saved  overlays 
!!  Display  realtime  tracks 
■b  Reports 
L::  Create  OPT  ASK 
■!  Create  Intel  Request 
88  Create  Planning  Docs 
'-B  T actical  Environment 
Lss  Input  Surf  Observation 
■8  Input  Beach  Profile 
88  Run  Surf  Forecast 
::  Run  Tide  Forecast 


Route  Links  |  Route  Specs  |  Craft  Info 
Route :  LHA2B1 


Leg  Start  Position 

End  Position 

Length 

Course 

Speed  (kts) 

Jjl  3708.1293N  02131. 7633E 

3708.1293N  02131.8870E 

3.2 

089 

5.0 

H  3708  1293N  02131  8870E 

3708.1 314N  021 33.7420E 

1.48 

095 

5.0 

JS  3708.1 31 4N  02133.7420E 

3708. 1 45 IN  02 132. 5561 E 

0.51 

075 

3.0 

H  3708. 1293N  02131.7633E 

3708.1293N  02131. 8870E 

0.10 

041 

2.0 

Q  3708. 1 293N  02 1 3 1  8870E 

3708.1 31 4N  02133.7420E 

1.48 

028 

5.0 

H  3708.1 31 4N  Q2133.7420E 

3708. 1 451 N  021 32.5561  E 

0.51 

075 

5.0 

Avg  Speed  over  Water 

12  knots 
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n/a 

Unload  Time  Mobile  Cargo 

10  min 

Unload  time  BlK  CWBO 

30  min 

Refueling  Time 

15  mm 

Max  Cargo  Weight 

180 

Max  Cargo  Square  Feet 

2300 

Figure  5.  New  EDSS  user  interface  prototype  recommendation 
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Based  on  the  feedback  from  the  prototype,  the  HCI  team  recommended  that  the  following 
features  be  included  in  a  new  EDSS  user  interface: 

•  Task  Manager  (TM):  lists  supertasks  and  their  corresponding  tasks  and  subtasks  as  a 
vertical  workflow  graph.  The  TM  also  has  a  Task  Index  that  lists  all  tasks  in  alphabetical 
order  and  provides  a  hyperlink  to  the  appropriate  task  element  in  the  TM  workflow. 

•  Map  Window  (MW):  displays  the  selected  map  from  Global  Combat  Support  System- 
Maritime  (GCCS-M)  and  geographic  overlays  created  by  EDSS.  The  other  windows 
form  around  the  periphery  of  the  MW. 

•  Asset  Manager  (AM):  provides  a  list  of  all  map  objects,  such  as  the  routes  the  user  has 
created  and  the  craft  the  user  has  chosen  to  include  in  the  plan.  With  the  AM  the  user  is 
able  to  view  the  number  and  status  of  routes  and  craft.  The  AM  shows  all  objects’ 
relationship  to  one  another. 

•  Working  Window  (WW):  groups  all  data  for  an  object  or  task  in  one  location.  Different 
types  of  data  for  an  object  or  task  are  accessible  via  tabs.  When  the  user  selects  a  task,  all 
of  the  screens  of  data  are  displayed  in  the  WW  in  a  tabbed  format.  This  lets  the  user 
know  immediately  upon  selecting  a  task  or  object  what  types  of  data  can  be  edited.  Data 
entry  fields  that  flow  in  a  linear  fashion  for  a  task  are  listed  with  tabs  from  left  to  right. 
This  mimics  the  workflow. 

•  Playback  Bar  (PB):  allows  the  user  to  perform  one  of  the  following:  1)  play 
forward/backward;  2)  step  forward/backward  in  increments  (user  specified — one  hour, 
one  minute,  one  second,  for  example);  or  3)  step  to  the  beginning  or  end  using  the  buttons 
at  the  right  of  the  Playback  Area. 

Implementation 

These  recommendations  were  presented  and  refined  during  several  meetings.  The  EDSS 
developers  accepted  the  recommendations  with  a  particular  preference  for  the  following:  1) 
docking  structure  that  prevents  window  overlays;  2)  separation  of  air  from  surface  routes  with 
solid  and  dotted  lines;  3)  green  signifying  a  required  task,  orange  as  optional  tasks;  4)  playback 
bar  as  a  constant  on  the  screen,  allowing  users  to  execute  at  any  time  during  the  event  as  well  as 
during  mission  planning,  and  to  start  the  playback/scenario  at  any  point;  and,  5)  capability  to 
continually  check  the  effects  of  plan  implementation  and  changes. 

Although  there  was  some  support  for  the  idea  of  the  Asset  Manager  (AM),  this  section  of  the 
redesigned  UI  was  not  implemented.  We  still  believe,  however,  that  the  Asset  Manager  could 
add  important  functionality  because  it  shows  quickly  all  the  routes  and  the  geographic  areas  in 
current  use.  The  developers  considered  that  showing  everything  in  an  operational  area  could 
cause  confusion  because  there  are  hundreds  of  items.  However,  the  docking  structure  handles 
this  situation  through  the  use  of  layer  toggles  and  buttons  that  allows  users  to  decide  what 
additional  operational  areas  or  assets  are  displayed  during  the  planning  phase.  (Again,  this 
solution  is  based  on  the  object-action  interface  model.) 

Dockable  windows  means  that  what  is  not  deemed  germane  at  the  moment  can  be  hidden.  The 
docking  structure  is  a  tool  to  aid  planners  and  serves  as  a  memory  jog,  so  they  know  the  full 
range  of  possibilities  in  a  given  area.  It  is  important  to  reiterate  here  that  the  AM  provides  the 
number  and  status  of  both  linked  and  unused  routes  and  craft,  thus  indicating  what  is  missing  in  a 
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given  task.  Providing  these  capabilities  to  the  user  ensures  the  necessary  control  over  the 
planning  process. 

The  EDSS  developers  were  tasked  with  a  major  development  effort  that  required  rewriting  a 
feature-rich  application  in  a  new  programming  language  to  run  on  a  new  operating  system.  It  is 
understandable  that  they  could  not  implement  all  the  recommended  improvements  during  their 
initial  revision.  What  follows  is  an  analysis  of  EDSS  2.X  Windows-based  version  (Figure  6)  as 
it  relates  to  the  HCI  prototype. 


EBS  !  ■  I 


irt  JBQ55  |  '-§)I55flIC  -  the  ...  |  Q5AIC  an 


Figure  6.  Implemented  EDSS  2.X  Windows-based  version 


EDSS  2.X  Windows-based  Version 

To  review,  in  EDSS  l.X  UBV  user  windows  popped  up  over  other  windows.  This  created  a 
cluttered,  confusing  interface.  It  was  often  difficult  to  access  the  map  or  other  windows  when 
needed  because  the  overlays  could  obscure  other  windows  completely. 

The  HCI  team’s  proposed  solution  was  a  docking  version  of  the  EDSS  interface.  Instead  of 
windows  overlaying  each  other,  a  set  area  was  established  for  each  window.  User  input  and 
navigation  windows  also  docked  to  the  main  map  window,  which  allowed  users  to  see 
everything  at  one  time,  maximizing  screen  space.  If  a  window  needs  to  be  larger,  the  user  can 
click  the  maximize  button  to  enlarge  the  specified  window. 
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EDSS  2.X  WBV  utilizes  a  docking  structure  that  allows  user  input  and  navigation  windows  to  be 
viewed  concurrently  with  the  main  map  window.  But  the  WBV  could  utilize  more  panes  in 
order  to  present  more  data  at  the  same  time. 

In  the  EDSS  l.X  UBV  users  had  a  difficult  time  finding  menu  items  to  carry  out  task 
assignments.  For  each  assignment  there  was  a  series  of  tasks  to  complete  in  a  particular  order. 
The  menu  items  in  the  UBV  did  not  correspond  to  any  particular  workflow,  and  as  a  result,  users 
became  confused  as  they  tried  to  find  the  items  necessary  to  carry  out  an  assignment.  In 
addition,  it  was  difficult  for  users  to  remember  all  of  the  steps  necessary  to  carry  out  an 
assignment. 

The  HCI  prototype  listed  tasks  and  subtasks  in  a  vertical  workflow  tree  located  in  a  docked 
window  to  the  left  of  the  main  map.  This  allowed  users  to  open  and  close  task  folders  and  to 
find  necessary  subtasks  to  carry  out  an  assignment  in  the  proper  order.  Users  could  select  any 
item  in  any  order,  but  the  layout  of  the  workflow  provided  a  visual  reference  for  the  user  with  a 
suggested  order  for  each  task  to  be  performed. 

EDSS  2.X  WBV  provides  a  vertical  workflow  graph  located  in  a  docked  window  to  the  left  of 
the  main  map.  It  provides  a  list  of  tasks  and  subtasks  in  a  folder  tree  structure.  The  menu  is 
organized  by  user  tasks,  providing  a  visual  reference  for  the  user  on  how  to  carry  out  tasks  and 
subtasks.  The  map  remains  visible  on  the  screen  at  all  times  as  does  the  working  window. 

In  EDSS  1  .X  the  playback  controls  were  difficult  to  use,  and  prevented  the  user  from  playing  the 
simulation  at  anything  other  than  a  fixed  rate.  Although  the  HCI  team  has  not  tested  EDSS  2.X, 
we  assume  that  the  EDSS  l.X  UBV  programming  has  not  been  modified  to  correct  this  situation 
because  of  the  considerable  difficultly.  However,  it  is  important  to  note  that  EDSS  2.X  is 
undergoing  a  redesign,  EDSS  3.X,  based  on  user  input,  which  will  further  user  enhancements. 
This  redesign  has  become  an  iterative  process  that  correctly  places  the  user  at  the  center. 
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V.  Conclusions 

We  were  tasked  to  investigate  possible  improvements  to  the  human-computer  interaction  of  the 
EDSS  and  provide  recommendations  to  the  system’s  development.  The  recommendations  of  the 
HCI  team  were  of  value  in  an  effort  to  convert  the  EDSS  from  a  Unix-based  (l.X)  to  a 
Windows-based  version  (2.X).  To  achieve  this  goal,  we  adopted  a  user-centered  design 
approach  (UCD). 

Following  the  principles  of  UCD  we: 

•  Observed  EDSS  users 

•  Observed  EDSS  training 

•  Studied  the  EDSS  interface 

•  Observed  people  completing  expeditionary  warfare  planning  tasks  in  the  field 

•  Interviewed  Marine  Corps  and  Navy  personnel 

•  Completed  an  in-depth  review  of  expeditionary  warfare  planning  doctrine 

Based  on  these  observations  and  studies  we  developed  a  preliminary  expeditionary  warfare  user 
task  analysis  (Appendix  B)  and  a  solutions  design  for  a  new  EDSS  user  interface  (Appendix  C). 
The  EDSS  development  team  accepted  many  of  our  recommendations.  The  most  significant 
changes  implemented  by  the  team  were  the  recasting  of  the  windowing  framework  and  a  new 
workflow  menu  structure. 

The  EDSS  developers  had  a  difficult  task.  They  not  only  had  to  convert  current  functionality 
from  one  operating  system  to  another,  but  they  also  wanted  to  improve  the  overall  “look  and 
feel”  of  the  application.  In  order  to  help  them  envision  our  proposed  changes,  we  developed  a 
medium-fidelity  prototype  of  the  EDSS  interface.  This  prototype  proved  useful  during  design 
meetings  and  may  have  accelerated  the  acceptance  of  our  recommendations. 

Our  task  ended  before  we  were  able  to  complete  a  usability  study  of  the  EDSS  version  2.X. 
While  observational  data  have  not  been  collected  to  determine  if  the  recommended  user  interface 
changes  are  a  measurable  improvement,  informal  feedback  has  shown  that  users  have  welcomed 
the  new  interface  because  of  its  enhanced  clarity  and  improved  workflow  (G.  Palmer,  personal 
communication,  January  20,  2004).  If  EDSS  continues  to  evolve  and  additional  capabilities 
added,  a  comprehensive  usability  study  would  ensure  that  the  software  continues  to  meet  user 
needs  and  sponsor  expectations. 

The  one  area  of  concern  is  that  while  EDSS  has  improved  greatly,  the  present  development  plan 
may  not  meet  the  desired  goal  of  creating  a  comprehensive  expeditionary  warfare  decision 
support  system  that  supports  decision  making  in  the  new  paradigm  of  Net  Centric  Warfare 
(NCW).  This  military  strategic  initiative  recognizes  that  the  human  user  of  technological 
systems  is  at  the  center  of  all  activity.  The  NCW  concept  has  implications  now  and  far  into  the 
future  for  transforming  military  operations.  Some  of  its  most  important  tenets  include: 
improving  the  speed  of  command,  creating  a  greater  shared  awareness,  increasing  collaborative 
planning  and  execution,  breaking  down  barriers  to  essential  information,  and  increasing  the 
speed  of  information  from  the  producer  to  the  user.  EDSS  can  have  a  role  in  all  of  these  issues. 


TR  0402 


22 


UNIVERSITY  OF  WASHINGTON  •  APPLIED  PHYSICS  LABORATORY. 


For  several  reasons,  however,  EDSS  may  fall  short  of  NCW  goals.  First,  the  majority  of  current 
EDSS  users  (based  on  our  observations  and  discussions)  are  typically  junior  personnel.  Meeting 
their  needs,  and  incorporating  their  feedback  into  upgrades,  may  limit  the  wider  use  of  EDSS  by 
the  senior  level  planners  for  whom  EDSS  was  initially  designed.  Second,  EDSS  needs  to  include 
more  high-level  tasks/goals  of  these  senior  decision  makers.  This  need  has  been  documented  in 
the  user  task  analysis.  Lastly,  and  most  significantly,  the  rapidly  evolving  technology  of  Net 
Centric  Enterprise  Services  needs  to  be  included  in  subsequent  EDSS  iterations. 

Our  final  assessment  is  that  there  are  key  improvements  that  EDSS  should  incorporate  to  meet 
the  future  needs  of  NCW  including: 

•  Real-time  collaboration  through  the  development  of  a  common  planning  picture 

•  Web  services  technology  that  allows  for  multiple  station  and  platform  independent 
planning 

•  Security  services  pioneered  for  NCW  to  allow  information  sharing  that  is  typically 
compartmentalized,  yet  essential  for  big  picture  analysis 

•  Tools  designed  and  developed  for  senior  decision  makers  that  focus  on  increasing  their 
situational  awareness 
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Appendix  A:  UCD  Workshop  Agenda  and  References 


Workshop  on  User-centered  Design  (UCD)  Considerations  for  EDSS 
Date:  30  July  2002 

Place:  SAIC  Headquarters,  Tysons  Corner,  VA 

Sponsor:  Office  of  Naval  Research,  Littoral  Combat  FNC 

Agenda: 

Introduction  &  Overview:  Bob  Miyamoto 
UCD  General  Principles:  Jim  Balias 


0830-0845 

0845-0900 

0900-1000 


UCD  Principles  Applied  to  the  Expeditionary  Warfare  Domain:  David 
Jones 

1000-1050:  Past  examples  of  UCD  applications:  DMARS  &  Environmental  Site 

Analyzer:  Bob  Miyamoto 

1050-1100:  Break 

1100-1200:  EDSS  Issues  &  MEDAL  COE  4.X  Example:  Shawn  Faust 

1200-1300:  Lunch 

1300-1345:  Open  Discussion:  Identification  of  HCI  &  UCD  Issues  for  EDSS 

1345-1430:  Interface  Design  and  Evaluation:  Jim  Balias 

1430-1530:  HCI  from  a  User  Perspective:  Janet  Olsonbaker  &  Troy  Tanner 

1 530-16 1 5 :  HCI  as  an  Instance  of  Language  Use:  Derek  Brock 

1615-1630:  Break 

1630-1700:  Review  and  Wrap-up:  David  Jones 


UCD  References  for  the  Workshop 

Books 

Vredenburg,  Karel;  Scott  Isensee,  Carol  Righi.  User  Centered  Design:  An  Integrated  Approach, 
2001 

Lewis,  Clayton  &  John  Rieman.  Task-Centered  User  Interface  Design:  A  Practical  Introduction, 
1994 

Web  Links 

http://www-3.ibm.com/ibm/easv/eou  ext.nsf/Publish/570  (good  site  with  a  lot  of  info  on  UCD) 
http://www.user-centereddesign.com/index.html  (a  company  specializing  in  UCD  services) 
http://www.well.com/user/riander/obstacles.html  (addressing  obstacles  to  UCD) 
http://www.cognetics.com/lucid/  (Web  site  devoted  to  logical  user-centered  interaction  design) 
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http://www.stcsig.org/usability/topics/articles/ucd%20  web  devel.html  (how  to  design  a  UCD 
Web  site) 

http : //www. ej  eisa. com/nectar/inuse/ 6.2/ contents .htm  (handbook  of  UCD — hyperlinked  on  Web 
site) 

http://hcibib.org/tcuid/  (HTML  version  of  the  book:  Task-Centered  User  Interface  Design:  A 
Practical  Introduction,  by  Clayton  Lewis  and  John  Rieman) 
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Appendix  B:  Expeditionary  Warfare  Decision  Support  System 
(EDSS) — Final  Report  on  User  Task  Analysis 

Report  Overview 

This  is  the  final  report  of  the  EDSS  User  Task  Analysis  project.  For  the  purposes  of  this  report 
we  have  defined  user  as  any  person  at  the  command  and/or  staff  level  involved  in  planning 
amphibious  operations.  We  evaluated  the  Joint  Doctrine  for  Amphibious  Operations  and  the 
Marine  Corps  Planning  Process  (MCPP)  depending  on  the  subtask  being  analyzed  and  the 
doctrinal  source  with  the  best  information  on  the  process.  The  goal  of  this  analysis  is  to  help 
facilitate  the  human-computer  interface  design  process  for  EDSS.  All  questions  about  this  work 
should  be  directed  to  James  Balias  at  NRL-DC. 

This  report  is  divided  into  the  following  sections 

•  Initial  NRL  Analysis 

•  Tasks  Analysis  Methodology 

•  Task  Analysis  Results 

Mission  Analysis  -  MCPP 

Analyze/Select  Landing  Area  &  Analyze/Select  Landing  Beach  -  Joint  Planning 
Process 

Course  of  Action  Development  -  MCPP 
Conduct  Detailed  Planning  -  EDSS  HCI  Mapping 
Definitions  and  Doctrinal  Sources 


Initial  NRL  Analysis 

The  initial  analysis  conducted  by  NRL  is  shown  in  the  diagram  below.  Several  elements  of  this 
diagram  are  worth  noting.  First,  high  level  planning  guidance  comes  from  the  national  command 
level  and  is  focused  on  strategic  objectives  and  Joint  and/or  coalition  operations  (shown  in  the 
rectangular  box).  Second,  the  left  side  of  the  diagram  indicates  amphibious  planning  process 
under  a  Joint  command  structure,  while  the  right  side  of  the  diagram  indicates  that  detailed 
planning  is  typically  planned  by  separate  Navy  and  Marine  Corps  commanders.  Third,  the 
Amphibious  Planning  process  depicted  on  the  left  of  the  diagram  illustrates  the  six  step  planning 
model  used  by  Joint  and  Marine  planners. 

For  the  purpose  of  this  report  the  first  two  steps  of  mission  planning  process  were  analyzed  - 
Mission  Analysis  and  COA  Development.  The  middle  arrow  indicates  an  initial  breakdown  of 
the  task  analysis  for  COA  selection  process.  The  right  arrow  indicates  the  Detailed  Planning  task 
analyses.  Subject  matter  expertise  was  derived  from  both  Joint  and  Marine  Corps  Planning 
Process  doctrine.  The  overall  task  hierarchy  shown  below  was  used  for  the  subsequent  task 
analyses. 
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Sea  and  Landing  Force 

Sea  and  Landing  Force  Joint  Command  Separate  Command 


Amphibious  Planning  Mission  and  Selection  of  COA 

Coordinate  GCCS.  Intelligence,  Strategic  Objectives. 
JCS I  National  Command  Level 


Amphibious  COA  Planning  Conduct  Detailed 

Planning  and  Selection  Planning 


Task  Analysis  Methodology 

The  general  task  analysis  methodology  is  similar  to  approaches  used  in  human  factors  and 
systems  engineering.  Typically,  higher  order  tasks  are  broken  down  into  manageable  subtasks 
and  analyzed  as  a  sequence  of  steps.  A  formal  task  analysis  often  involves  observing  users  of  a 
system  and  building  and  testing  prototypes  to  measure  task  performance.  Due  to  constraints  of 
this  project  an  abbreviated  informal  task  analysis  was  used  in  its  place.  The  subject  matter 
expertise  used  to  analyze  the  tasks  are  based  on  current  military  doctrine  combined  with  the 
results  of  a  sea  trial  aboard  the  USS  Iwo  Jima  in  2002. 
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Task  Descriptions 

Each  task/subtask  was  analyzed  to  determine  what  information  is  needed  as  input  to  the  task, 
what  are  the  human  performance  requirements  essential  to  completing  a  task,  who  are  the 
decision  makers,  what  are  the  cognitive,  perceptual,  and  analytical  stages  used  in  the  planning 
process,  and  what  products  are  produced  such  as  maps,  narratives,  instructions,  guidelines,  and 
other  data  used  during  planning  and  mission  execution.  This  information  is  incorporated  into  a 
task  record  shown  below,  which  is  part  of  each  task  analysis. 

Task  Record 

Informational  Requirements  (Inputs) 

NEMTL  Human  Performance  Metrics  (Requirements) 

Primary  Decision  Makers  (Commander  Level) 

Process  (Cognitive  Analysis) 

Product  (Outputs) 


Mission  Analysis 

Mission  Analysis  is  the  first  step  in  planning  an  amphibious  operation.  The  purpose  of  mission 
analysis  is  to  review  and  analyze  orders,  guidance,  and  other  information  provided  by  a  higher 
command  and  produce  a  mission  statement  that  drives  the  rest  of  the  amphibious  planning 
process. 

Mission  Analysis  using  Joint  planning  process  and  the  MCPP  are  very  similar.  The  User  Task 
Analysis  in  this  report  is  based  on  the  MCPP  doctrinal  publication  MCWP  5-1  W/CH  1,  9/24/01 

The  task  analysis  method  is  the  same  that  was  used  in  prior  analyses  of  Course  of  Action 
development,  and  the  Detailed  Planning  for  EDSS. 


Task  Analysis 

A  graphic  depiction  of  the  Mission  Analysis  process  is  shown  below.  This  model  does  not  do 
justice  to  the  issues  of  concurrent  planning  steps  where  multiple  components  of  the  Mission 
Analysis  planning  are  done  in  parallel.  This  model  also  does  not  reflect  the  highly  iterative 
process  used  at  the  command  and  staff  levels  when  building  the  analysis  plan. 
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TASK:  Marine  Commander  Reviews  Orders 

Information 

Requirements 

Input  from  higher  command  as  WO,  OPORD,  or  OPPLAN.  Intel  on 
friendly/enemy  forces,  battlespace,  situational  awareness 

Performance 

Requirements 

Primary  Decision 
Makers 

Commander 

Process 

Commanders  Orientation:  Begins  planning  process  by  visualizing  battlespace 
and  mission  and  communicates  this  vision  to  the  OPT  through  the  most 
important  element  of  the  CBAE  -  the  commanders  intent.  This  is  directed  at 
both  planners  and  executors.  This  focuses  on  the  enduring  part  of  a  mission, 
the  “why”.  As  situational  awareness  grows  the  commander  may  refine  his  intent 
using  an  iterative  purpose-method-end  state  paradigm. 

Commanders  Guidance:  Guidance  is  directed  to  the  planners  and  provides 
the  battle  staff  and  OPT  with  additional  insight  about  the  resources  needed  to 
accomplish  the  mission,  and  what  the  force  needs  to  do.  It  might  be  based  on 
the  six  warfighting  functions,  or  the  sequence  of  actions  to  produce  the  desired 
end  state.  This  is  handed  off  to  subordinate  commanders  and  the  OPT 

Products 

CBAE 

EDSS  HCI  Mapping 

TASK:  OPT  Briefs  Staff  on  Commanders  Intent  and  Purpose  of  Mission 

Information 

Requirements 

CBAE,  Higher  Command  Intel  and  IPB  products 

Performance 

Requirements 

Primary  Decision 
Makers 

Chief  of  staff,  OPT,  G-2,  and  subordinate  battle  staff 
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OPT  leads  the  planning  process  and  focuses  on  the  “how”  and  “what”  of  the 
mission  -  meaning  the  strategy/tactics  and  identifying  the  necessary  resources. 
Identifies  the  purpose  of  the  mission.  Briefs  planning  and  battle  staff  on  Higher 
HQ  CONOPS  so  they  understand  how  their  operation  fits  into  a  larger  mission 

Process 

OPT  briefs  the  staff  on  the  current  enemy/friendly  situation,  Intel,  IPB  products, 
and  the  purpose  of  the  mission  and  the  Commanders  Intent  and  assists  the  G-2 
in  the  planning  process.  Ensures  that  the  staff  understands  the  command 
relationships  internal  to  the  Joint  force  and  the  MAGTF 

Products 

CCIRs 

EDSS  HCI  Mapping 

TASK:  Identify  Tasks  Needed  to  Accomplish  Mission 

Information 

Requirements 

Commander  Guidance,  OPORD 

Performance 

Requirements 

Primary  Decision 
Makers 

OPT,  G-2,  and  subordinate  battle  staff 

Process 

Identification:  Identifies  tasks  necessary  to  accomplish  mission  including 
specified,  implied,  and  essential  tasks.  Implied  tasks  should  be  linked  to 
specified  tasks  that  are  not  SOP.  Essential  tasks  apply  to  the  force  as  a  whole 
and  form  the  basis  of  the  mission  statement. 

Analysis:  Implied  tasks  are  derived  by  analysis  of  how  the  unit  will  accomplish 
the  specified  tasks  across  the  six  warfighting  functions.  COG  provided  by  G-2 
and  Commanders  orientation  are  analyzed.  OPT  analyzes  the  area  of  interest 
and  influence,  and  the  AO  to  determine  if  additional  resources  will  be  required 

Products 

Task  list  (specified,  implied,  essential)  contained  in  OPORD 

EDSS  HCI  Mapping 

TR  0402 


32 


UNIVERSITY  OF  WASHINGTON  •  APPLIED  PHYSICS  LABORATORY- 


TASK:  Review  Available  Assets  and  Identify  Shortfalls 

Information 

Requirements 

Task  list,  OPORD,  COG, 

Performance 

Requirements 

Primary  Decision 
Makers 

Commander,  OPT 

Process 

Identify  assets  and  resource  shortfall,  flesh  out  SME  shortfalls,  determine 
additional  constraints  and  restraints,  determine  assumptions,  proposes 
additional  CCIR’s  to  commander,  identifies  additional  RFI  to  be  submitted  to 
higher  HQ  in  the  commanders  name, 

Products 

CCIR’s,  RFI’s 

EDSS  HCI  Mapping 

TASK:  Draft  Mission  Statement 

Information 

Requirements 

OPORD,  all  prior  products  and  documents 

Performance 

Requirements 

Primary  Decision 
Makers 

Commander 

Process 

OPT  prepare  a  mission  analysis  brief  and  WO  for  the  commander.  This  is  an 
iterative  process  that  may  follow  the  purpose-method-end  state  model.  Once 
approved  the  OPT  develops  recommendations  for  commanders  planning 
guidance  and  issues  mission  statement. 

Products 

WO,  Mission  Statement,  Commander  Intent  and  Planning  Guidance,  CONOPS, 
CCIR’s,  command  relationships.  Orders  for  preliminary  actions  such  as  Recon 
and  Survail,  staging  logistics,  special  equipment  requirements,  time  lines, 
planning  meetings, 

EDSS  HCI  Mapping 
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Joint  Planning  Process 

This  section  describes  the  joint  planning  process  used  to  plan  an  amphibious  operation 
integrating  Navy  and  Marine  commands.  The  JPP  is  very  similar  to  the  MCPP.  The  six  step 
model  is  show  below. 


An  amphibious  operation  is  an  integrated  plan  jointly  developed  by  the  CATF  and  CLF  as 
indicated  in  the  Joint  Doctrine  for  Amphibious  Operations.  The  CATF  is  a  naval  officer  and  CLF 
can  apply  equally  to  a  Marine  and/or  Army  command.  (In  Chapter  IV:  Approach  to  Planning  and 
Primary  Decisions  the  Marine  Corps  or  Army  is  not  mentioned  and  are  referred  to  as  the 
“landing  force”.)  The  steps  in  planning  a  COA  for  a  Joint  Amphibious  Operation  is  shown  in  the 
diagram  below. 

Integral  to  the  Joint  planning  process  is  developing  the  COA,  which  is  the  most  difficult  part  of 
the  process.  The  general  planning  in  Steps  1-4  are  broken  down  into  10  Primary  Decisions 
indicating  who  owns  which  decision.  Joint  decisions  are  made  by  the  CATF  and  CLF  commands 
mutually  (1-6,  10),  and  individually  (7-9).  The  order  of  decision  making  approximates  the  logic 
and  flow  of  the  six  step  model. 
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NATO  Decision  Matrix  (Comparison  Only) 


NATO  planning  is  not  analyzed  but  a  broad  decision  matrix  is  shown  below  to  compare  the 
NATO  process  with  the  Joint  planning  process.  This  chart  is  shown  for  comparison  reasons.  The 
overall  decision  process  closely  parallels  the  Joint  sequence  (while  the  tasks  themselves  differ). 
One  of  the  greatest  distinctions  is  the  CLF  has  much  more  responsibility  in  the  NATO  matrix 
because  of  the  greater  complexity  of  the  mission  when  having  to  coordinate  between  coalition 
and  multinational  forces.  Note:  This  process  resembles  the  matrix  in  the  10/8/1992  version  of  JP 
3-02. 
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Two  subtasks  were  selected  for  analysis.  The  grey  boxes  on  the  right  of  the  diagram  indicate  the 
subtasks  that  were  analyzed  under  COA  Development.  The  graphic  below  depicts  the  JPP  in 
greater  detail  and  the  two  subtasks  that  were  analyzed:  Analyze  /  Select  Landing  Area,  Analyze 
/  Select  Landing  Beaches 


Task  Analysis  Results 

The  purpose  of  the  UTA  was  to  understand  two  subtasks  conducted  in  the  Joint  planning 
process  as  shown  below  in  the  grey  shaded  boxes.  Two  subtasks  were  analyzed.  The 
hyperlink  goes  directly  to  the  task  analysis  record  for  each  task. 
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Analyze  and  Select  Landing  Area 


Information 

Requirements 

Naval  Considerations:  Ability  to  support  the  landing  and  subsequent  operations; 

Degree  of  shelter  from  sea  and  weather;  Hydrography  of  beach  approaches  off-shore  and 
near  shore  including  tidal  information,  beach  gradient,  beach  exits,  terrain  bordering 
beach  and  Naval  desirability;  Extent  of  mineable  waters;  Hostile  ability  to  defeat  mine 
countermeasures;  Practicality  of  improving  unloading  facilities;  Hostile  disposition  and 
capabilities;  Possibility  of  early  seizure  and  rehabilitation  of  port  facilities 

(Source:  JP  3-02  - 
9/19/2001) 

Marine  Considerations:  Landing  area  must  be  suitable  for  conventional,  displacement 
landing  craft  and  causeway  ferries.  Requires  data  on  beach  head,  transport  areas,  fire 
support  areas,  airspace  operated  by  close  supporting  aircraft,  land  included  in  the  inland 
to  accomplish  objectives,  hostile  capabilities,  coastline  configuration  inland  terrain, 
combat  service  support  requirements 

Shown  Graphically 

(Marine)  Air  Considerations:  Ability  to  achieve  and  maintain  local  air  superiority  and 
perform  interdiction  and  close  air  support;  Own  forces  locally  based  air  warfare 
capabilities;  Command  and  control  capabilities  and  deconfliction  ability;  ability  to 
support  the  landing  and  subsequent  operations;  Hostile  counter  air  capabilities  and 
disposition;  possibility  of  early  seizure  and  rehabilitation  of  facilities 

Ship-to-Shore  Considerations:  In  development 

Performance 

Requirements 

MCPP  detail  the  performance  requirements  for  amphibious  assault,  demonstration,  and 
withdrawal. 

M8:  Y/N  Did  assault  meet  the  stated  objectives? 

Ml 0:  >  90  %  of  execution  checklist  completed  on  time? 

Source:  CVBG  Warfare  Commander’s  NMETL  version  1.3;  Naval  Mission  Essential 

Task  List  (NMETL)  Development  Handbook 

CATF  designates  potential  landing  sites  and  provides  the  CLF  with  information 

Primary  Decision 
Makers 

The  CATF  weighs  the  capabilities  of  the  naval  force,  the  operational  requirements  for 
the  air,  land  and  sea  areas.  CATF  delineates  the  sea  area  and  airspace  requirements  to 
establish  each  beachhead  tentatively  selected  by  the  CLF 

Process 

Select  COA  |  Analyze  Landing  Area  |  Selection  of  Landing  Area 

Full  Guidance  for  this  process  is  detailed  in  MSTP  5-0.2 

Products 

COA  graphic  and  narrative.  See  Figure  6-2  in  MCWP  5-1  w/CHl  (page  41) 

Diagram  of  Landing  Area 
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Example  of  COA  Diagram  and  Narrative 


GRAY  CITY 


XVIII 


On  order  MEF  conducts  an  envelopment  to  defeat  enemy  first  operational  echelon 
forces  north  of  Gray  City.  Close  Operations:  in  the  east  a  division  conducts  a 
supporting  attack  in  zone  to  fix  the  first  tactical  echelon.  In  the  west  a  division,  as 
the  MAIN  EFFORT,  attacks  along  AXIS  SWORD  and  defeats  the  second  tactical 
echelon.  Reserve:  A  regiment  follows  the  main  effort  prepared  to  contain  enemy 
forces  capable  of  threatening  the  main  efforts  movement  south.  If  not  committed 
north  of  PL  Teal,  the  reserve  is  prepared  to  block  enemy  reinforcements  from  the 
south.  Deep  Operations:  MAW  initially  disrupts  the  402nd  Artillery  Regiment’s 
ability  to  mass  fires  on  the  main  effort  and  limits  the  103rd,  104th  Armored 
Brigades,  and  the  204th  Mechanized  Brigade  from  reinforcing  the  first  tactical 
echelon.  When  the  main  effort  crosses  PL  Teal  the  MAW  disrupts  enemy  second 
operational  echelon  forces  from  committing  to  the  MEF  zone.  Rear  Operations:  A 
battalion  task  force  acts  as  the  MEF’s  TCF  with  the  priority  of  responding  to  a 
Level  El!  Threat  to  the  MEF:s  class  Hi  fuel  depot  vicinity  Greentown  to  ensure  the 
uninterrupted  flow  of  Class  III.  The  FSSG  establishes  CSSA  in  vicinity  of  Tealton 
and  Grey  City  to  provide  combat  service  support  to  MEF  units.  Security:  The 
MAW  screens  to  the  west  to  protect  the  MEF’s  western  flank.  This  phase 
concludes  with  enemy  first  operational  echelon  forces  defeated  north  of  Gray  City. 


Figure  6-2.  Course  of  action  graphic  and  narrative. 
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Landing  Area  Diagram 


LANDING  AREA  DIAGRAM 


1.  CONTROL  SHIPS'  STATIONS  ARE  NOT  FIXED  AND  MAY  BE  ASSIGNED  UNDERWAY  SECTORS  TO  AVOID  SNORE-BASED  THREATS. 


2.  AAV  LAUNCHES  MAY  TAKE  PLACE  WITH  THE  LAUNCH  SHIP  UNDERWAY  IN  THE  AAV  LAUNCHING  AREA. 
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Landing  Area  Selection  Considerations  -  Graphic  Representation  from  JP  3-02 


OSMSet&T** 


LANDING  AREA  SELECTION 


AbiHly  to  achieve  and  maintain 
local  air  superiority  and  perform 
interdiction  and  dose  air  support 

Own  forces  Locally  based  air 
warfare  capabilities 

Command  and  control  capabilities 
to  include  deconflicUon  ability 


Ability  to  support  the  landing 
and  subsequent  operations 

Hostile  counterair  capabilities 
and  disposition 

Possibility  of  early  seizure 
and  rehabil  Italian  of  fac  il  Iti  es 


Ability  to  support  the  landing 
and  subsequent  operations 

Degree  of  shelter  from  sea  and 
weather 


on  areas 


onshore,  end  near 


Extent  of  mineable  waters 
Hostile  ability  to  defeat  mine 


Hostile  capabilities  and 


Possibility  of -early  seizure  and 
rehabilitation  of  pW facilities 


■Kri-: 


IDERAT 


Suitability  of  landing  area 
Hostile  capabilities 
Coastline  configuration 
Inland  terrain 


7sm 


Combat  service  support 
requirements 

Fossiblity  of  early  seizure  and 
rehabilitation  of  air  facilities 


Analyze  /  Select  Landing  Beach 


Selected  after  the  landing  area  has  been  determined.  Landing  beaches  are  selected  from 
within  the  selected  landing  areas. 

Information 

Requirements 

Landing  beach  is  that  portion  of  a  shoreline  usually  required  for  the  landing  of  a  battalion 
landing  team.  Or  might  be  the  portion  of  the  shoreline  that  is  a  tactical  locality  (such  as 
the  shore  of  a  bay)  where  a  force  should  be  landed. 

(Source:  JP  3-02  - 
9/19/2001) 

Factors  important  to  selecting  a  landing  beach  include  the  Naval,  Marine,  and  Joint 
criteria  used  in  selecting  a  landing  area.  Suitability  for  landing  craft  and  AAVs.  Offshore 
approaches  and  tidal  conditions.  Number,  location,  and  suitability  of  beach  support  areas, 
beach  exits,  and  nearby  infrastructure.  Landing  beaches  are  designated  by  color  and 
subdivisions  designated  by  number  (e.g.  Green  beach,  Red  Beach  1). 

Ship-to-Shore  Considerations:  In  development 
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Performance 

Requirements 

More  detailed  information  included  in  MSTP  and  Student  Document  handout. 

Primary  Decision 
Makers 

Mutual  decision  between  CATF  and  CLF 

Select  COA  |  Analyze/Select  Landing  Area  |  Analyze  Landing  Beach  |  Select 

Landing  Beach 

Process 

Commanders  and  staff  must  also  begin  developing  their  “commanders  guidance  for 
fires”,  ensure  the  JFC  targeting  process  is  shaping  fires  and  integrating  them  into  a  joint 
fire  support  plan 

COA  graphic  and  narrative.  See  Figure  6-2  in  MCWP  5-1  w/CHl  (page  41) 

Products 

Diagram  of  Landing  Area 

MCPP — COA  Development 

The  Marine  Corps  have  developed  their  own  internal  planning  process  that  compliments  the 
deliberate  or  CAP  (crises  action  planning)  outlined  in  JOPES  (Joint  Operation  Planning  and 
Execution  System).  The  MCPP  is  virtually  identical  to  the  Joint  Planning  Process,  the  same  six 
step  model  is  used  for  planning  as  shown  below.  The  differences  come  with  respect  to 
determining  the  COA  at  the  detailed  planning  level. 


Marine  Corps  Planning  Process 

This  section  describes  the  task  analysis  for  determining  the  COA  as  documented  in  the  MCPP 


Description  of  Planning  Steps 

1 .  Mission  Analysis  -  The  first  step  in  planning  with  the  purpose  to  review  and  analyze  orders, 
guidance,  and  other  information  provided  by  higher  headquarters  and  produce  a  mission 
statement.  This  step  drives  the  remainder  of  the  process.  Similar  for  JOPES  and  MCPP. 
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2.  COA  Development  -  A  COA  is  a  broadly  stated  potential  solution  to  an  assigned  mission. 
The  COA  development  step  of  the  process  is  designed  to  generate  options  for  follow-on  war 
gaming  and  comparison  that  satisfy  the  mission,  intent,  and  guidance  of  the  commander. 

3.  COA  War  game  -  The  COA  war  game  allows  the  commander,  his  staff,  and  the  OPT  to  gain 
a  common  understanding  of  friendly  and  threat  COAs.  The  war  game  helps  determine  the 
advantages  and  disadvantages  of  each  COA  and  allows  war  fighting  functions  to  be 
synchronized  across  the  battlespace  (close,  deep,  and  rear).  It  also  identifies  branches  and 
potential  contingency  plans  for  changing  the  mission. 

4.  COA  Comparison  /  Decision  -  In  COA  comparison  and  decision,  the  commander  evaluates 
all  friendly  COAs  against  established  criteria,  then  against  each  other,  and  selects  the  COA  that 
best  accomplishes  the  mission.  The  commander  may  refine  the  mission  statement  (including  the 
commander’s  intent  and  essential  tasks),  concept  of  operations,  and  identify  any  branches  of  the 
chosen  COA  that  should  be  developed.  This  step  requires  the  involvement  of  the  commander,  the 
subordinate  commanders,  and  their  staffs  from  start  to  finish. 

5.  Orders  Development  -  Orders  development  communicates  the  commander’s  intent, 
guidance,  and  decisions  in  a  clear,  useful  form  that  is  easily  understood  by  those  who  must 
execute  the  order.  The  order  should  only  contain  critical  or  new  information — not  routine  matters 
normally  found  in  SOPs.  The  chief  of  staff  or  the  executive  officer,  as  appropriate,  directs  orders 
development. 

6.  Transition  -  Transition  ensures  a  successful  shift  from  planning  to  execution.  It  enhances  the 
situational  awareness  of  those  who  will  execute  the  plan,  maintains  the  intent  of  the  concept  of 
operations,  promotes  unity  of  effort,  and  generates  tempo. 

Joint  and  Individual  Commands 

The  diagram  below  depicts  the  task  analysis  of  the  MCPP  and  specifically  the  planning  process 
used  to  develop  a  COA.  The  left  side  showing  the  six  step  planning  model  is  a  Joint  planning 
operation  between  the  Navy  and  Marine  commands.  The  more  detailed  planning  of  the  COA  on 
the  right  is  the  internal  process  used  by  the  Marines  for  planning  the  COA  for  an 
amphibious  operation. 
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Joint  Naval/Marine  Command 
CATF  /  CLA 


Marine  /  CLF 


Coordinate  GCC5,  Intelligence,  Strategic  Objectives, 
JCS  /  National  Command  Level 


The  process  of  developing  a  COA,  war  gaming  it,  assessing  the  outcomes  of  each  COA  and 
gaming  them  with  each  other  is  a  highly  iterative  and  fluid  process.  The  plans  developed  must  be 
flexible  enough  to  deal  with  changing  theater  and/or  situational  requirements. 

COA  development  is  shown  on  the  right  side  of  the  diagram,  and  is  an  internal  process 
undertaken  by  the  Corps.  There  are  11  tasks  in  the  process.  The  diagram  implies  an  ordered 
contiguous  process,  but  in  reality  many  of  these  tasks  are  performed  in  parallel,  or  non- 
sequentially  based  on  the  interdependencies  of  each  of  the  tasks. 
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Task  Analysis  Results 


The  COA  is  a  potential  solution  to  an  assigned  mission.  Developing  a  COA  is  an  iterative 
process  designed  to  generate  multiple  action  plans,  war  game  them,  then  evaluate  and  select  the 
best  COA. 


Information 

Requirements 

(Source: 

MCWP  5-1  w/CHl) 

Command  Level  Input:  Mission  statement,  commanders  intent,  and  commanders 
planning  guidance 

Input  Products:  Updated  IPB  products  (enemy  CO  As,  doctrinal,  situational,  and  event 
templates,  high  value  targets);  Specified,  Implied  and  Essential  Tasks,  Warning  Order; 
Restraints/constraints;  Assumptions;  Resource  and  SME  shortfalls;  COG  analysis 
(friendly,  enemy);  Approved  CCIR’s;  RFIs’  Initial  staff  estimates 

Performance 

Requirements 

Course  of  Action  Criteria:  Make  sure  COA  satisfies  requirements  for  Suitability, 
Feasibility,  Acceptability,  Distinguishability,  and  Completeness 

Primary  Decision 
Makers 

The  Commander  in  cooperation  with  the  OPT  (Operations  Planning  Team); 

Details  on  the  command  and  control  are  delineated  in  accordance  with  the 

concepts  and  principles  in  JP  0-2,  Unified  Action  Armed  Forces  (UNAAF). 
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1.  Commanders  Intent  /  Planning  Guidance:  The  OPT  concentrates  on  the  following 
two  questions:  What  do  we  want  to  do?  How  do  we  want  to  do  it? 

2.  Threat  Assessment  and  COG:  OPT  first  focuses  on  the  enemy  then  reviews  the 
friendly  situation.  Looks  at  relative  combat  power  to  use  friendly  strengths  (COGs)  to 
exploit  enemy  critical  vulnerabilities  in  developing  CO  As.  The  OPT  uses  the  information 
products  specified  above. 

3.  Designate  Objective  /  Main  Effort:  Identify  the  main  effort  by  stage  to  help  develop 
tasks  for  supporting  units 

4.  Describe  Scheme  of  Maneuver:  Deep,  Close,  and  Rear  operations 

5.  Determine  Fire  Support  Coordination  Measures:  In  coalition  operations  it  is 
essential  to  use  doctrinally  accepted  and  clearly  understand  fire  support  and  control 
measures  to  facilitate  coalition  cross  boundary  fires  and  minimize  fratricide 

Process 

6.  Reserve  Units:  Identify  location  and  conditions  for  committing  the  reserves 

7.  Use  Realistic  Movement  Rates:  Ensure  they  are  based  on  actual  capabilities  and  the 
effects  of  weather  and  terrain.  See  MSTP  5-0.3  MAGTF  Planner’s  Reference  Manual 

8.  Review  Mission  Analysis:  Review  commanders  and  guidance/  This  might  allow  the 
OPT  to  recommend  new  CCIR 

9.  Develop  COA  Graphic  and  Narrative:  Depict  unit  symbols  and  other  graphics 
correctly.  Check  COA  narratives  to  insure  all  subordinate  units  have  been  tasked.  This 
product  must  clearly  describe  how  the  unit  will  accomplish  its  mission  and  describe  the 
scheme  of  maneuver.  A  more  detailed  list  of  requirements  and  outputs  is  described  in 
MCWP  5-1  w/CHl  Part  VI:  COA  Development. 

10.  Ensure  Conformance  with  Commanders  COA  Criteria:  Ensure  COAs  meet  the 
COA  criteria  both  generic  (MWCP  5-1)  and  specific  commander  planning  guidance 

11.  Prepare  Supporting  Concepts  for  each  COA:  Make  sure  all  actions  are  integrated 
and  synchronized.  Once  the  commander  selects  a  COA  for  CONOPT  these  provide  the 
basis  for  concepts  of  Intel,  Fires,  Logistics,  maneuver. 

COA  graphic  and  narrative.  See  Figure  6-2  in  MCWP  5-1  w/CHl  (page  41) 

Products 

Supporting  documents  and  maps  and  information 

OPORD  or  OPPLAN 
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Task  Analysis:  Conduct  Detailed  Planning 

The  EDSS  menu  structure  was  analyzed  to  map  the  existing  HCI  functionality  to  a  detailed 
functional  analysis  of  the  tasks  described  below.  The  diagram  highlights  the  Conduct  Detailed 
Planning  process  (in  bold  boxes).  Three  primary  User  Tasks  were  identified 

Define  Assets 

Define  Sea  and  Landing  Geometry 
Design  Schedule 

These  tasks  were  broken  down  into  their  associated  Products  shown  as  the  smaller  boxes  to  the 
right  of  each  task. 


Amphibious  Planning  Mission  and  Selection  of  COA 

Coordinate  GCCS,  Intelligence,  Strategic  Objectives,  JCS 
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Joint  Mission  Essential  Task  List  (JMETL)  Development  Handbook 
VBG-WC-Amph-NMETL.xls 
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User  Task  Data  Structure 


TASK:  Define  Assets 

PRODUCT:  Landing  Craft 

Information 

Requirements 

Types  and  number  of  landing  craft  relevant  to  the  operation  that  are  available  for  each 
ship  in  the  landing  force.  Need  to  know  the  capabilities  or  have  a  resource  available. 

Performance 

Requirements 

TBD 

Primary  Decision 
Makers 

EDSS  Users 

Actions  Taken:  Create  an  inventory  of  available  craft  with  capabilities. 

Process 

Decision  Making:  Appropriateness  of  each  for  the  tactical  situation  and  conditions. 
Need  for  maintaining  reserves  and/or  need  for  naval  support. 

Products 

List  of  landing  craft  available  for  landing  force  with  default  craft  parameter  knowledge. 

EDSS  HCI  Mapping 

Planning  :  Documents  :  Landing  Craft  Performance  /  Landing  Craft  Availability 

TASK:  Design  Sea  and  Landing  Area  Geometry  PRODUCT:  Sea  Echelon  Area 

Information 

Requirements 

Ship  information:  Names,  Types,  Current  disposition;  Load  out;  Area  information: 
Environmental  (tides,  winds),  Landing  priority  table;  Assault  Schedule:  wave  numbers, 
timing,  beaches,  units,  serials;  Gunfire  support  schedule;  ATO 

Performance 

Requirements 

Produce  Grid  TBD.  Meets  OP  requirements 

Primary  Decision 
Makers 

EDSS  Users 
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Process 

Actions  Taken:  Review  OPORD,  Landing  Plan,  Other  Messages;  Review  Commander’s 
Intentions;  Layout  map  to  be  used  to  make  grid;  Understand  map  scale;  Choose  grid 
type;  Name  grid;  Layout  grid;  Produce  detailed  grid  data  (position,  axis,  segment  size); 
Add  labels  at  desired  positions;  Add  graphical  information  (e.g.,  color);  Calculate  comer 
points;  Assign  ships  to  grid  segments 

Decision  Making:  Grid  location,  Grid  size,  Grid  geometry,  Axis  disposition,  Number  of 
segments,  Segment  size,  Labeling,  Ship  assignment  and  reassignment 

Products 

4WG  with  Ships  Assigned 

EDSS  HCI  Mapping 

Areas:  Directory:  Grid 

TASK:  Design  Sea  and  Landing  Area  Geometry  PRODUCT:  Beaches  and  Boat  Lanes 

Information 

Requirements 

Data  from  intelligence  -  either  HUMINT  with  GPS  receiver  or  imagery  sources. 
Information  about  minefields,  exits.  Metoc  information  to  include,  information 
regarding  prevailing  winds,  currents,  lunar  data.  Suitability  for  landing  craft  in  use. 

Performance 

Requirements 

Produce  diagram  of  the  beach  and  boat  lane  in  XX  minutes  that  meets  all  tactical 
requirements. 

Primary  Decision 
Makers 

EDSS  Users 

Actions  Taken:  Review  all  available  intel.  Collaborate  with  participant  commands  to 
insure  decisions  meet  all  operational  requirements.  Produce  detailed  description 
(position,  size);  Add  labels  at  desired  positions;  Add  graphical  information  (e.g.,  color). 

Process 

Decision  Making:  Beach,  beach  size,  boat  lane  width,  depth,  need  for  extension. 

Display  data. 

Products 

Defined  beach  and  boat  lane. 

EDSS  HCI  Mapping 

Area:  Directory:  Boat  Lane 
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TASK:  Design  Sea  and  Landing  Area  Geometry  PRODUCT:  Route(s) 

Information 

Requirements 

Which  craft  are  to  be  used  in  wave.  Ingress  and  egress  routes.  Beach  and  inland, 
METOC  data,  appropriate  craft  speed  for  legs  of  routes  given  sea  conditions. 

Performance 

Requirements 

Efficient  use  of  sea/land  air  space  for  ingress  and  egress 

Primary  Decision 
Makers 

EDSS  Users 

Process 

Actions  Taken:  Review  all  transit  conditions  to  determine  need  for  modifications  in 
planning.  Produce  a  detailed  diagram  of  routes.  Add  labels  and  graphical  information 
as  required. 

Decision  Making:  Routes  which  match  terrain,  hostile  constraints,  and  meets  tactical 
requirements  for  air,  sea,  and  land  movements. 

Products 

Graphic  with  landing  routes  and  overland  transit 

EDSS  HCI  Mapping 

Area:  Directory:  Route 

TASK:  Design  Schedule  PRODUCT:  Landing  Force  Landing  Plan 

Information 

Requirements 

Landing  plan(s)  will  need  default  landing  craft  parameters  with  modifications  required 
by  conditions.  Serial  load  information  to  determine  factors  contributing  to  on  and  off 
load  times  and  other  mission  critical  timing. 

Performance 

Requirements 

Produce  a  workable  landing  plan  in  collaboration  with  all  mission  participants. 

Primary  Decision 
Makers 

EDSS  Users 

Actions  Taken:  Review  serial  load  data  for  efficient  on  and  off  load  of  equipment. 
Review  all  information  from  all  sources  to  select  optimal  H-hour. 

Process 

Decision  Making:  Timing  of  transits  to  and  from  ship  to  shore  and  to  and  from  beach 
and  HLZ  to  objective. 
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Products 

Landing  Plan 

EDSS  HCI  Mapping 

Planning:  Plan 

Doctrinal  References 

The  resources  used  to  analyze  the  planning  process  were  derived  from  military  doctrine.  The 
primary  doctrinal  sources  that  were  referenced  are  shown  in  the  list  below: 

Joint  Doctrine  for  Amphibious  Operations  -  Joint  Pub  3-02,  9/19/2001 

Joint  Doctrine  for  Landing  Force  Operations  -  Joint  Pub  3-02.1,  1/1/1999 

Joint  doctrine  governs  the  joint  activities  of  the  US  military  for  multinational  and  interagency 
operations  and  provides  guidance  to  Joint  Force  Commanders.  This  doctrine  takes  precedence 
over  Service  doctrine  unless  directed  by  the  JCS.  In  terms  of  amphibious  warfare  planning  joint 
doctrine  incorporates  both  Naval  and  Marine  Operations. 

Marine  Corps  Planning  Process1  -  MCWP  5-1  W/CH  1,  9/24/01 

Marine  Corps  doctrine  (MCPP)  are  intended  for  Marine  Corps  operations  with  a  unitary 
command  and  recognizes  the  commanders  central  role  as  the  decision  maker,  and  also  joint 
operations  with  a  shared  Naval  command. 

Rapid  Response  Planning  Process  (R2P2)  -  EWTGLANT,  Ops  3.1 

NATO  Doctrine  for  Amphibious  Operations  -  NATO  ATP  8(A)(B),  Vol.  1 

NATO  doctrine  is  oriented  towards  multinational  operations  and  the  coordination  and  planning 
of  US  Armed  Forces  with  Allied  forces  (as  well  as  Joint  Task  Force  and  Joint  Commands).  A 
quick  check  of  NATO  doctrine  was  consistent  with  the  MCPP  and  Joint  Doctrine. 


1  Formally  MSTP  Pamphlet  5-0.2  -  Operational  Planning  Team  Guide,  Part  IV,  3/01 


Terms  and  Definitions 

Amphibious  operation  (JP  1-02)  An  attack  launched  from  the  sea  by  naval  and  landing  forces 
embarked  in  ships  or  craft  involving  a  landing  plan  on  a  hostile  or  potentially  hostile  shore.  As 
an  entity,  the  amphibious  operation  includes  the  following  phases:  A.  planning  -  The  period 
extending  from  issuance  of  the  initiating  directive  to  embarkation.  B.  embarkation  -  The  period 
during  which  the  forces,  with  their  equipment  and  supplies,  are  embarked  in  the  assigned 
shipping.  C.  rehearsal  -  The  period  during  which  the  prospective  operation  is  rehearsed  for  the 
purpose  of  (1)  testing  adequacy  of  plans,  the  timing  of  detailed  operations,  and  the  combat 
readiness  of  participating  forces;  (2)  ensuring  that  all  echelons  are  familiar  with  plans,  and  (3) 
testing  communications.  D.  movement  -  The  period  during  which  various  components  of  the 
amphibious  task  force  move  from  points  of  embarkation  to  the  objective  area.  E.  assault  -  The 
period  between  the  arrival  of  the  major  assault  forces  of  the  amphibious  task  forces  in  the 
objective  area  and  the  accomplishment  of  the  amphibious  task  force  mission. 
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Beach  capacity  (JP  1-02)  An  estimate,  expressed  in  terms  of  measurement  tons,  or  weight  tons, 
of  cargo  that  may  be  unloaded  over  a  designated  strip  of  shore  per  day. 

Course  of  action  (JP  1-02)  1.  a  plan  that  would  accomplish,  or  is  related  to,  the  accomplishment 
of  a  mission.  2.  The  scheme  adopted  to  accomplish  a  task  or  mission.  It  is  a  product  of  the  Joint 
Operation  Planning  and  Execution  System  concept  development  phase.  The  supported 
commander  will  include  a  recommended  COA  in  the  commander’s  estimate.  The  recommended 
COA  will  include  the  concept  of  operations,  evaluation  of  supportability  estimates  of  supporting 
organizations,  and  an  integrated  time-phases  data  base  of  combat,  combat  support,  and  combat 
service  support  forces  and  sustainment.  Refinement  of  this  data  base  will  be  contingent  on  the 
time  available  for  COA  development.  When  approved,  the  COA  becomes  the  basis  for  the 
development  of  an  operation  plan  or  operation  order 

Landing  area  (JP  1-02)  The  part  of  the  objective  area  within  which  are  conducted  the  landing 
operations  of  an  amphibious  force.  It  includes  the  beach,  the  approaches  to  the  beach,  the 
transport  areas,  the  fire  support  areas,  the  air  occupied  by  close  supporting  aircraft,  and  the  land 
included  in  the  advance  inland  to  the  initial  objective. 

Landing  beach  (JP  1-02)  That  portion  of  a  shoreline  usually  required  for  the  landing  of  a 
battalion  landing  team.  However,  it  may  also  be  that  portion  of  a  shoreline  constituting  a  tactical 
locality  (such  as  the  shore  of  a  bay)  over  which  a  force  larger  or  smaller  than  a  battalion  landing 
team  may  be  landed. 

Landing  plan  (JP  1-02)  In  amphibious  operations,  a  collective  term  referring  to  all  individually 
prepared  naval  and  landing  force  documents  that,  taken  together,  present  in  detail  all  instructions 
for  execution  of  the  ship-to-shore  movement. 

Mission  (JP  1-02)  1.  The  task,  together  with  the  purpose,  that  clearly  indicates  the  action  to  be 
taken  and  the  reason  therefore. 

Mission  Analysis.  (JP  3-02)  Review  and  analyze  orders,  guidance,  and  other  information 
provided  by  the  establishing  authority  in  the  order  initiating  the  amphibious  operation  and  to 
produce  an  amphibious  force  mission  statement(s).  Produces  planning  guidance  that  will  focus 
the  staffs  in  COA  development.  Makes  the  following  decisions:  determine  amphibious  force 
mission;  select  amphibious  force  objectives.  The  input  is  the  higher  commander’s  warning  order, 
OPLAN  or  OPORD. 

Operation  order  (OPORD)  (JP  1-02)  A  directive  issued  by  a  commander  to  subordinate 
commanders  for  the  purpose  of  effecting  the  coordinated  execution  of  an  operation. 

Operation  plan  (OPLAN)  (JP  1-02)  Any  plan,  except  for  the  Single  Integrated  Operation  Plan, 
for  the  conduct  of  military  operations.  Plans  are  prepared  by  combatant  commanders  in  response 
to  requirements  established  by  the  Chairman  of  the  Joint  Chiefs  of  Staff  and  by  commanders  of 
subordinate  commands  in  response  to  requirements  tasked  by  the  establishing  unified 
commander.  Operation  Plans  (OPLANS)  are  prepared  in  either  a  complete  format  (OPLAN)  or 
as  a  concept  plan  (CONPLAN).  The  CONPLAN  can  be  published  with  or  without  a  time-phased 
force  and  deployment  data  (TPFDD)  file.  An  OPPLAN  for  the  conduct  of  joint  operations  can  be 
used  as  a  basis  for  development  of  an  operation  order  (OPORD).  An  OPPLAN  identifies  the 
forces  and  supplies  required  to  execute  the  CINC’s  Strategic  Concept  and  a  movement  schedule 
of  these  resources  to  the  theater  of  operations.  The  forces  and  supplies  are  identified  in  TPFDD 
files.  OPLANS  will  include  all  phases  of  the  tasked  operations.  The  plan  is  prepared  with  the 
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appropriate  annexes,  appendixes,  and  TPFDD  files  as  described  in  the  Joint  Operation  Planning 
and  Execution  System  manuals  containing  planning  policies,  procedures  and  formats. 

Sea  echelon  area.  (JP  3-02)  In  amphibious  operations,  an  area  to  seaward  of  a  transport  area 
from  which  assault  shipping  is  phased  into  the  transport  area,  and  to  which  assault  shipping 
withdraws  from  the  transport  area. 

Scheme  of  maneuver  (JP  1-02)  The  tactical  plan  to  be  executed  by  a  force  in  order  to  seize 
assigned  objectives.  See  FM  101-5. 

Serial  (JP  1-02)  An  element  or  a  group  of  elements  within  a  series  which  is  given  a  numerical  or 
alphabetical  designation  for  convenience  in  planning,  scheduling  and  control. 

Serial  assignment  table  (JP  1-02)  A  table  that  is  used  in  amphibious  operations  and  shows  the 
serial  number,  the  title  of  the  unit,  the  approximate  number  of  personnel;  the  material,  vehicles, 
or  equipment  in  the  serial,  the  number  and  type  of  landing  craft  and/or  amphibious  vehicles 
required  to  boat  the  serial;  and  the  ship  on  which  the  serial  is  embarked. 

Staff  estimates  (JP  1-02)  Assessments  of  CO  As  by  the  various  staff  elements  of  a  command  that 
serve  as  the  foundation  of  the  commander’s  estimate. 

Stowage  plan  (JP  1-02)  A  completed  stowage  diagram  showing  what  material  has  been  loaded 
and  its  stowage  location  in  each  hold,  between-deck  compartment,  or  other  space  in  a  ship, 
including  deck  space. 

Subsequent  operations  phase  The  phase  of  an  airborne,  air  assault,  or  amphibious  operation 
conducted  after  the  assault  phase.  Operations  in  the  objective  area  may  consist  of  offense, 
defense,  linkup,  or  withdrawal. 

Warning  order  (WARNO)  (JP  1-02).  1.  A  preliminary  notice  of  an  order  or  action  which  is  to 
follow.  2.  A  crisis  action  planning  directive  issued  by  the  Chairman  of  the  Joint  Chiefs  of  Staff 
that  initiates  the  development  and  evaluation  of  COA  by  a  supported  commander  and  requests 
that  a  commander’s  estimate  be  submitted.  3.  A  planning  directive  that  describes  the  situation, 
allocates  forces  and  resources,  establishes  command  relationships,  provides  other  initial  planning 
guidance,  and  initiates  subordinate  unit  mission  planning. 
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Appendix  C:  User  Interface  Design  Recommendations  for  EDSS 

Recommendations  Summary 

This  section  includes  the  recommendations  APL-UW  made  for  redesigning  the  EDSS  graphical 
user  interface  (GUI).  These  recommendations  are  reinforced  by  the  results  of  the  User  Task 
Analysis  of  Expeditionary  Warfare  Planning  (see  Appendix  B).  Users  have  been  observed  at 
several  locations — on  several  ships  and  during  one  amphibious  exercise.  With  the  identification 
of  user  tasks,  the  menus  and  buttons  were  designed  to  reflect  these.  These  recommendations 
were  offered  to  improve  the  usability  of  the  EDSS  GUI. 

The  GUI  needs  to: 

•  keep  the  map  window  in  the  center  of  the  user’s  vision;  all  other  interface  windows 
form  around  the  map  window 

•  restrict  window  proliferation  by  using  a  single  working  window  with  tabbed  panes 

•  offer  a  workflow  listing  as  a  series  of  tasks  that  segue  directly  to  the  required  data 
entry  tabs 

•  provide  an  asset  manager  window  that  links  objects  in  the  map  window  to  their 
individual  data  entry  tabs 

•  provide  a  quick  way  to  animate  a  COA  with  a  playback  slider  bar 

•  provide  a  consolidated  list  of  all  tasks  that  provides  a  hyperlink  to  the  actual 
workflow  task 

•  provide  “tool  tip”  pop-ups  (abbreviated  help  explanations)  when  the  user  moves  the 
mouse  over  key  elements  of  the  GUI 

Overview  of  the  Improved  Graphical  User  Interface 

The  recommended  EDSS  GUI  was  divided  into  five  sections:  Task  Manager,  Map  Window, 
Asset  Manager,  Working  Window,  and  Playback  Bar  (Figure  A3-1).  Each  component  resides 
in  a  separate  window.  By  default,  the  windows  are  docked  together  in  the  configuration  below. 
Each  of  the  four  main  windows  can  be  maximized  to  fill  the  entire  screen,  or  the  windows  can  be 
undocked  and  arranged  in  a  different  order,  if,  for  example,  the  user  has  dual  monitors. 
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GCSS-M  Menu  Bar 

Task 

Manager 

Map  Window 

Asset 

Manager 

Playback  Bar 

Working  Window 

Figure  A3-1.  Location  of  EDSS  window  components 


System  Chart  Views  Comms  Misc  Intel  Troubleshoot  System  Lite 


System  Map  Options  Plot  Control  Tracks  Support  TDAs  FOTC/Best  TDAs  Slides  MIW  EDSS 


Task  Manager  [■[ 


Working  Window  4WGRID1 
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Segment  Directory 


Segment  Color  Fill  Type 


Q  OPAREA1 


Figure  A3 -2.  APL-LFW  prototype  4W  Grid  creation 
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All  modules/windows  have  a  maximize  button  that  allows  them  to  fill  the  entire  screen.  This  is 
primarily  for  the  Map  Area  and  Working  Window,  each  of  which  can  contain  large  amounts  of 
data.  The  default  GUI  layout  implements  a  tiling  structure  that  allows  the  user  to  view  many 
types  of  data  concurrently.  The  maximize  button  allows  the  user  to  give  more  screen  space  to  a 
selected  module/window  when  there  is  too  much  data  for  a  smaller  window. 

•  Task  Manager  (TM)  lists  supertasks  and  their  corresponding  tasks  and  subtasks  as  a 
vertical  workflow  graph.  TM  also  has  a  Task  Index  that  lists  all  tasks  in  alphabetical 
order  and  provides  a  hyperlink  to  the  appropriate  task  element  in  the  TM  workflow. 

•  Map  Window  (MW)  displays  the  selected  map  from  Global  Combat  Support  System- 
Maritime  (GCCS-M)  and  geographic  overlays  created  by  EDSS.  The  other  windows 
form  around  the  periphery  of  the  MW. 

•  Asset  Manager  (AM)  provides  a  list  of  all  map  objects,  such  as  the  routes  the  user  has 
created  and  the  craft  the  user  has  chosen  to  include  in  the  plan.  With  the  Asset 
Manager  the  user  is  able  to  view  the  number  and  status  of  routes  and  craft.  The  AM 
shows  all  objects’  relationship  to  one  another. 

•  Working  Window  (WW)  groups  all  data  for  an  object  or  task  in  one  location. 

Different  types  of  data  for  an  object  or  task  are  accessible  via  tabs.  When  the  user 
selects  a  task,  all  of  the  screens  of  data  are  displayed  in  the  working  window  in  a  tabbed 
format.  This  lets  the  user  know  immediately  upon  selecting  a  task  or  object  what  types 
of  data  can  be  edited.  Data  entry  fields  that  flow  in  a  linear  fashion  for  a  task  are  listed 
with  tabs  from  left  to  right.  This  mimics  the  workflow. 

•  Playback  Bar  (PB)  The  user  can  perform  one  of  the  following:  1)  play 
forward/backward;  2)  step  forward/backward  in  increments  (user  specified — one  hour, 
one  minute,  one  second,  for  example);  or  3)  step  to  the  beginning  or  end  using  the 
buttons  at  the  right  of  the  Playback  Area. 

Details  of  the  Interface  Components 

The  Task  Manager 

•  When  the  mouse  is  clicked  on  the  task  name  in  the  TM  it  turns  light  green  and  all  tasks 
under  it,  required  or  optional,  unroll. 

•  If  the  mouse  is  clicked  on  the  task  a  second  time,  the  task  returns  to  its  unlighted  status 
and  the  items  roll  up. 

•  The  color  green  indicates  that  a  task  is  a  required  step  of  the  workflow.  A  green  bar 
connecting  two  tasks  indicates  the  user  must  perform  one  or  the  other  of  the  tasks. 
Orange  indicates  the  task  is  an  optional  step. 

•  Each  supertask  only  contains  the  tasks  required  to  complete  its  workflow.  The  Index 
option  at  the  bottom  lists  every  possible  subtask  needed  to  carry  out  a  task,  such  as 
building  an  Op  Area.  Tasks  are  listed  alphabetically. 

•  When  a  user  selects  a  subtask,  the  task  name  and  box  turn  to  white  in  the  Task  Area, 
and  the  task  data  screens  are  displayed  in  the  Working  Window. 

•  The  tool  tips  clarify  the  meaning  of  the  green  and  orange  coding  of  the  outline  bullets, 
as  well  as  the  meaning  of  the  connecting  bars  between  the  bullets. 
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The  Menu  Hierarchy 

The  task  organization  in  the  Task  Manager  follows  the  general  workflow  for  expeditionary 
planning,  but  it  is  understood  that  the  EDDS  program  may  be  used  for  a  variety  of  subtasks 
outside  of  the  full  plan  development.  The  TM  allows  for  quick  navigation  to  the  tasks  used  most 
often. 

Table  A3-1  is  a  comparison  of  the  APL-UW  prototype  menu  structure  to  EDSS  l.X  UBV  menu 
structure.  The  left  column  is  in  the  order  that  the  proposed  menu  structure  should  appear,  while 
the  right  column  is  the  original  EDSS  1  .X  menus.  There  is  not  a  one-to-one  correlation  between 
the  two.  The  prototype  menu  structure  is  an  attempt  to  create  a  workflow  task  list.  Some  of  the 
tasks  that  appear  currently  in  subwindows  have  been  brought  into  the  menu  list.  (Note:  the 
inactive  menus  of  EDSS  l.X  have  not  been  shown.) 


Table  A3-1. 


Prototype  EDSS  Menu  System 

EDSS  l.X  Menu  System 

Expeditionary  Planning 

System 

Establish  OpArea 

Version  1.1. 0.5 

New 

Open 

Operational  Areas 

Save 

New  Area  ... 

Delete 

Load  ... 

External  Import 

Save  ... 

External  Export 

Delete  ... 

Import . . . 

Export . . . 

Exit 

Asset  Management 

Reports 

Landing  Craft  Performance 

Landing  Craft  Performance  . . . 

Landing  Craft  Availability 
Helo  Availability 

(combine  w/  Asslt  Plans) 

AAV  Availability 

Craft  Parameters. . . 

Serial  database 

Landing  Craft  Availability  . . . 

Helo  Availability  . . . 

AAV  Availability 

Logistics 

Serial  Database  . . . 
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Geographic  Overlays 

Sea  Echelon  Areas 

Freehand 

4W  Grid 

Location 

Size 

Data 

Labels 

Boat  Lane 

Create 

Edit 

Delete 

Q  Routes 

Create 

Edit 

Delete 

Helo  Landing  Zone 

Add 

Edit 

AO  A  Mgmt 

Areas  . . . 

4W  Grid  Assignments  . . . 

Asset  Positions... 

Courses  of  Action 

Landing  Plan  Data 

Landing  Craft  Employment 

Helo  Employment 

AAV  Employment 

Assault  Plans 

Plan  Data 

Landing  . . . 

Reports 

Landing  Craft  Employment . . . 

Helo  Employment. . . 

AAV  Employment. . . 

Execution  of  COA 

Logistics 

(new  functions) 

Serial  Tracking  . . . 

Serial  Tracking 

Display  saved  overlays 

Display  realtime  tracks 

Reports 

Reports 

Create  OPTASK 

Planning  Documents. . . 

Create  Intel  Request 

Create  Planning  Documents 
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Tactical  Environment 

Input  Surf  Observation 

Input  Beach  Profile 

Run  Surf  Forecast 

Run  Tide  Forecast 

Envr  DB 

Database 

Depth  Profile  . . . 

Models 

Surf  Forecast ... 

Surf  Observations  . . . 

Environmental  DB  (new  functions) 

Envr  DB 

Import  TEDS 

Database 

Import  Wave  Overlay 

Wave... 

Import  Weather  Overlay 

Training/Help 

Landing  Craft  Parameters 

Doctrine 

Lessons  Learned 

Simulated  Plans 

Task  Index 

Task  Manager  Explanation 

The  Task  Manager  has  two  purposes:  provide  a  list  of  all  the  tasks  a  user  can  perform,  and 
provide  a  workflow,  from  top  to  bottom,  of  each  task  and  its  subtasks.  There  are  several  top- 
level  tasks,  or  level  1  tasks  such  as  Expeditionary  Planning,  Environmental  DB,  Training/Help, 
etc.,  and  level  2  tasks  such  as  Establish  Op  Area,  Asset  Management,  Courses  of  Action, 
Execution  of  CO  A,  Reports,  and  Tactical  Environment.  Each  time  a  task  or  subtask  branches 
into  its  subtasks,  a  new  level  is  displayed.  Some  tasks  might  have  only  three  levels,  while  others 
have  five  or  six. 

To  indicate  if  a  task  or  subtask  has  other  subtasks,  a  plus  sign  is  displayed  in  an  icon  to  the  left  of 
the  task/subtask.  If  a  subtask  is  the  final  level,  no  sign  is  displayed  in  the  icon  to  the  left.  Green 
indicates  a  required  task/subtask,  and  orange  indicates  an  optional  task/subtask.  This  is  intended 
to  help  the  user  become  familiar  with  required  and  optional  steps  for  a  task.  If  two  subtasks  have 
their  icons  linked  together,  such  as  New  and  Open  under  Establish  Op  Area,  the  user  must  choose 
one  or  the  other,  meaning  that  the  step  is  required,  but  there  is  an  option  as  to  how  it  is  carried 
out.  The  above  explanation  should  be  included  under  the  “Help  Function.” 

The  Task  Index  contains  every  level  2  task  available  in  EDSS,  listed  alphabetically,  as  well  as  all 
of  their  subsequent  tasks.  Task  Index  is  intended  to  provide  a  place  where  a  user  can  perform 
one,  or  a  few  tasks,  without  having  to  work  within  the  workflow  of  a  top  level  task.  For 
example,  if  a  user  simply  needs  to  load  an  OpArea  and  build  a  4W  Grid,  rather  than  have  to  use 
the  workflow  for  Expeditionary  Planning,  the  user  opens  the  Task  Index,  and  uses  it  to  load  an 
OpArea  and  build  a  4W  Grid. 
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By  default,  when  a  user  selects  a  level  1  task,  all  level  2  and  3  tasks  are  displayed  for  that  task, 
listed  from  top  to  bottom.  Each  task  level  is  indented  to  the  right  of  the  previous  task  level. 
Displaying  levels  1  through  3  of  a  selected  task  is  intended  to  allow  the  user  to  see  the  general 
workflow  of  the  task  while  keeping  everything  on  one  screen  for  ease  of  viewing.  The  user  can 
expand  any  level  3  task  to  view  its  subsequent  subtasks  at  any  time.  This  allows  the  user  to 
decide  which  portions  of  the  workflow  to  view  in  detail.  At  the  top  of  the  TM  are  buttons 
labeled  1,  2,  3,  4,  5.  Clicking  one  of  these  buttons  expands/contracts  the  current  Level  1  Task  to 
Level  1,  2,  3,  4,  or  5.  This  gives  the  user  a  quick  way  to  expand  the  workflow  of  every  task  all 
the  way  to  level  5,  or  collapse  it  to  level  2  or  3  without  having  to  manually  click  the 
expand/collapse  icon  for  each  task/subtask. 


Working  Window 

•  Contains  tabbed  windows  that  provide  default  parameters  for  the  selected  task 

•  Clicking  on  a  tab  brings  that  tab  and  its  parameters  to  the  front 

•  These  parameters  can  be  edited,  or  blank  spaces  filled 

•  Some  parameters  may  be  chosen  from  a  predefined  set,  such  as  color. 

•  Some  tab  windows  may  require  additional  actions  from  the  user,  such  as  submitting 
edited  parameters  to  the  database;  these  should  appear  as  buttons  along  the  top  portion 
of  the  tabbed  window 

•  If  there  are  more  parameters  than  can  be  displayed  in  the  predefined  screen  area  for  the 
WW,  a  scroll  bar  will  appear  on  the  right  side  of  the  tab  window 


Researchers  found  this  window  to  be  the  most  complex  UI  for  EDSS.  Its  conversion  from  EDSS 
1.X  required  the  most  effort  in  the  UI  redesign.  Much  of  the  parameter  window  had  unused 
space  and  could  be  more  efficiently  presented  in  the  tabbed  view.  Other  parameter  windows 
needed  to  be  divided  into  separate  tab  windows. 


Asset  Manager 

•  The  Asset  Manager  (AM)  gives  the  user  a  complete  view  of  linked  routes  and  crafts, 
unused  routes,  and  unused  crafts,  all  of  which  can  be  independent  of  the  current  display 
in  the  WW 

•  The  AM  differs  from  the  TM  in  that  it  gives  the  user  the  relationship  of  each  element  in 
the  plan  to  every  other  element 

•  Selected  Objects  are  displayed  in  white 

•  Route  types  (solid  for  surface,  dotted  for  air)  and  route  colors  are  displayed  in  the  AM 

•  Icons  representing  craft  types  are  displayed  beside  the  craft  name;  the  AM  can  contain 
many  other  objects  as  well 

•  If  multiple  grids  are  in  a  plan,  they  are  displayed  in  the  AM  as  well 

•  Elements  in  the  plan  were  divided  into  a  tree  structure  in  each  section 
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The  AM  contains  a  list  of  every  object/component  that  the  user  has  added  to  EDSS:  OpAreas, 
Sea  Echelon  Areas,  Boat  Lanes,  Routes,  all  Vehicles,  etc.  The  AM  is  important  because  it  lists 
everything  the  user  has  added,  and  the  AM  can  be  edited.  It  is  also  important  because  it  shows 
the  user  what  has  not  been  added  to  the  scene,  i.e.,  what  pieces  are  missing  for  a  given  task.  Use 
of  EDSS  l.X  provoked  questions  such  as:  Are  there  routes  along  the  4W  Grid?  Is  there  a  Sea 
Echelon  Area  that  is  not  currently  displayed  in  the  map?  Which  vessels  follow  which  Routes? 
These  questions  can  be  answered  more  easily  if  there  is  a  place  on  the  screen  that  holds  every 
component.  EDSS  uses  a  map  screen  that  can  be  moved  and/or  magnified.  As  a  result, 
components  that  a  user  needs  to  access  are  often  not  on  the  screen. 

In  addition,  users  found  it  difficult  in  EDSS  l.X  to  determine  which  ships  and  types  of  ships 
were  linked  to  each  route.  The  surface  ship  icon  is  the  same  regardless  of  ship  type.  A  window 
that  provides  not  only  a  list  of  components,  but  icons  that  quickly  distinguish  ship/aircraft  types, 
and  provides  information  about  which  craft  are  linked  to  which  routes,  helps  the  user  make 
sense,  visually,  of  how  all  the  pieces  fit  together. 

The  AM  is  also  useful  when  one  user  creates  a  plan,  saves  it,  and  gives  it  to  another  user.  The 
new  user  should  not  have  a  difficult  time  figuring  out  what  components  are  included  or  missing. 
With  an  AM  any  user  has  a  quick,  efficient  way  of  viewing  a  plan  and  knowing  what  is  loaded  in 
the  plan  and  how  those  pieces  fit  together. 


Playback  Bar 

•  Displays  minimum  and  maximum  relative  H-hour  values  and  the  current  playback  time 

•  Can  drag  the  playback  slider  to  the  desired  time 

•  EDSS  played  1  .X  back  the  plan  one  frame  per  second  (fps).  It  would  be  useful  if  the 
user  could  select  the  video  frame  rate.  If  there  are  no  hardware  constraints,  i.e.,  if  the 
system  can  process  the  data  at  1  fps,  or  if  this  is  not  a  design  issue,  smooth  video  (24- 
30  fps)  conveys  accurate  motion  to  the  user,  and,  if  at  all  possible,  we  recommend  that 
it  be  implemented. 


The  Playback  Bar  (PB)  represents  a  timeline  from  a  user-specified  H-hour  to  a  user-specified 
H+hour.  One  use  of  the  PB  is  to  play  the  scenario  from  start  to  finish  once  the  user  has  loaded 
the  OpArea,  built  Sea  Echelon  Areas,  Boat  Lanes  and  Routes,  and  specified  which  vehicles 
follow  which  routes.  The  PB  gives  the  user  a  way  to  view  how  all  components  change  with 
time.  EDSS  l.X  playback  could  only  be  used  once  the  entire  plan  was  built.  This  method  does 
not  allow  the  user  to  check  the  playback  of  the  plan  as  it  is  being  built. 

It  would  be  helpful  if  the  user  could  add  a  boat  lane  and  a  ship  to  a  route,  and  then  be  able  to 
view  these  components  over  time.  As  users  add  each  component  they  could  use  the  playback  to 
see  ship  movement  coordination.  To  give  the  user  this  ability  to  view  components  that  move 
over  time  at  any  stage  in  the  plan  development,  the  PB  should  be  present  at  all  times.  It  should 
be  grayed  out  when  there  are  no  components  that  change  over  time,  and  then  displayed  in  its 
normal  state  once  the  first  time-dependent  element  is  added.  This  lets  users  know  when  they  can 
start  using  the  playback  feature.  If  for  some  reason  users  did  not  want  the  PB  visible,  they  could 
remove  it,  as  with  any  other  window,  but  it  should  be  visible  by  default  so  the  user  is  aware  of 
the  playback  feature  and  can  easily  step  forwards  and  backwards  along  the  timeline. 
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Map  Window 

Due  to  the  requirement  to  use  the  underlying  map  functions  of  GCCS-M,  we  recognize  that  there 
may  be  limitations  to  what  can  be  improved  in  the  map  window.  However,  we  do  have  various 
additional  recommendations  that  could  improve  the  clarity  of  the  overlays  produced  by  EDSS, 
but  we  need  to  further  investigate  what  is  possible  in  future  versions  of  EDSS  and  also  compare 
these  ideas  against  the  Defense  Information  Infrastructure  (DII)  user  interface  recommendations. 
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